Release Process Overview
After a release of Spot we expect: the release to be tagged in the git repository, the tarball to be available, Debian packages for both stable and unstable distributions to be available, the web site to be updated with the correct links and documentation, a mail to be have been sent to spot-announce, the next branch of the git repository to be ready to continue development with a different version number.
Part of the above process it automated. In particular the web pages are automatically constructed from the stable Debian packages. But a part of the work is still done manually. Use the following check list.
masterto 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
next for the procdure below.
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.
A couple of days before the release:
- Make sure
master(if maintenance release) or
next(if major release) has all the patches you want to release.
- Check on spot-dev that the online translator is still working. As the translator on spot-dev uses the
nextbranch, this is not a guarantee that the translator on spot.lrde.epita.fr (which uses the
stablebranch) will work, but its close enough.
- Check that the third-party tools installed in the docker containers are up-to-date.
The day of the release:
- Make sure
nextare fully green on the build farm.
- Read, complete, and clean up
masterfor maintenance or
nextfor major release).
- update the version number and release date in
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-Zwhere X-Y-Z corresponds to version X.Y.Z.
- adjust the branches (using hard resets or forward merges) so that master and stable point to the current commit
- push stable to the server, using the
--tagsoption to send the tag as well (the tag must be in the repository before you attempt to build the Debian packages)
- on branch,
.devthe the version number, update
NEWSfor this version, merge
next, and push both
- jump to the pipelines for spot, and cancel the duplicate pipeline for
master, keeping only
- while waiting for the
stablepipeline and the
nextpipeline to finish, prepare the announcement mail for spot-announce
- both the
nextpipelines will trigger builds of
spot-webproject, but one build will create the main website, and the other will create the development one. The
nextpipeline also trigger a build of the
spot-sandboximage. All those web containers are simply pushed to our docker registry, and they get deployed by a crontab that runs at xx:20 every hour.
- once the new web server is running well, send the announcement email
.devto the version number in
configure.ac, and add an empty entry at the top of
NEWSwith 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