... | ... | @@ -6,34 +6,38 @@ the next branch of the git repository to be ready to continue development with a |
|
|
|
|
|
Part of the above process it automated. In particular the web pages are automatically constructed from the stable Debian packages. But a large part of the work is still done manually. Use the following check list.
|
|
|
|
|
|
We use `master`to prepare maintenance releases, and `next` for major releases. Usually `master` has a collection of bug-fixes cherry-picked from `next`. Depending of whether we make maintenance release (x.y.z) or a major release (x.y), we will work from `master` or `next` for the procdure below.
|
|
|
|
|
|
The `stable` branch should point to the last release: it is used to build the stable Debian package that are in turn used to build the web page.
|
|
|
|
|
|
Release Procedure
|
|
|
-----------------
|
|
|
|
|
|
A couple of days before the release:
|
|
|
|
|
|
- If `master` is not already included in `next`, merge it.
|
|
|
- Make sure `master` (if maintenance release) or `next` (if major release) has all the patches you want to release.
|
|
|
- Check locally that the online translator page in `wrap/python/ajax/` is still working: it's not part of the test suite, but it will be installed on the web server.
|
|
|
- Check that the [third-party tools](https://github.com/adl/spot-docker/blob/master/debuild/install.sh) installed in the docker containers are up-to-date.
|
|
|
- Rebuild the docker containers ([gadl/spot-debuild](https://hub.docker.com/r/gadl/spot-debuild/) & [gadl/spot-debuild-i386](https://hub.docker.com/r/gadl/spot-debuild-i386/)) by triggering new builds on dockerhub. This will ensure that our Debian packages are built against the most recent version of all the other Debian packages they depend upon.
|
|
|
- Make sure `next` compiles with the new container for unstable (this is done every night after a new commit on `next`)
|
|
|
- Make sure `next` compiles with the new container for stable (you need to trigger this build by hand)
|
|
|
- Make sure `master` and `next` compile with the new container for unstable (this is done every night after a new commit on `next`)
|
|
|
- Make sure `master` and `next` compile with the new container for stable (you need to trigger this build by hand)
|
|
|
|
|
|
The day of the release:
|
|
|
|
|
|
- Make sure `next` is fully green on the build farm.
|
|
|
- Read, complete, and clean up `NEWS`
|
|
|
- Make sure `master` and `next` are fully green on the build farm.
|
|
|
- Read, complete, and clean up `NEWS` (on `master` for maintenance or `next` for major release).
|
|
|
- update the version number and release date in `configure.ac`, `NEWS`, and `doc/org/setup.org`. Beware about this last file: some of the macros are links that have to be updated with `C-c C-l` (review your diff carefully).
|
|
|
- commit the above version change locally
|
|
|
- tag the above commit with `git tag -a spot-X-Y-Z` where X-Y-Z corresponds to version X.Y.Z.
|
|
|
- hard reset master and stable to the current commit (or merge next into these two branches, it should have the same effect)
|
|
|
- push master, stable, and next on the server, using the `--tags` option to send the tag as well (the tag must be in the repository *before* you attempt to build the Debian packages)
|
|
|
- trigger a build of the Debian packages for both stable (branch stable) and unstable (branch next).
|
|
|
- adjust the branches (using hard resets or forward merges) so that master and stable point to the current commit
|
|
|
- push master, stable, and next (if changed) on the server, using the `--tags` option to send the tag as well (the tag must be in the repository *before* you attempt to build the Debian packages)
|
|
|
- trigger a build of the stable Debian packages (branch stable), and unstable (branch next) if it was modified.
|
|
|
- while the packages are built, prepare the announcement mail for spot-announce
|
|
|
- once the Debian packages are built, trigger a build of spot-www to update the docker containing the web-server
|
|
|
(Note that the web site uses the stable packages, while the sandbox and official tarball are generated from the unstable packages.)
|
|
|
(Note that the web site and official tarball are generated from the stable packages, while the sandbox is generated from the unstable packages.)
|
|
|
- wait for the next hour (the web server is updated by a crontab that runs at xx:20 every hour)
|
|
|
- check that the new web server is running well
|
|
|
- send the announcement email
|
|
|
- add `a` to the version number in `configure.ac`, and add an empty entry at the top of `NEWS` with this version number
|
|
|
- commit and push this change on branch next
|
|
|
- add `.dev` to the version number in `configure.ac`, and add an empty entry at the top of `NEWS` with this version number
|
|
|
- commit this change on master, and merge it into next (do not update `stable`, which should point to the release).
|
|
|
- update this page with any step that you found incorrect or missing |