GitLab

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.

We use 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 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:

• 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 installed in the docker containers are up-to-date.
• 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 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.
• 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 --tags option to send the tag as well (the tag must be in the repository before you attempt to build the Debian packages)
• on branch, master, add .dev the the version number, update NEWS for this version, merge master into next, and push both master and next.
• jump to the pipelines for spot, and cancel the duplicate pipeline for master, keeping only stable and next
• while waiting for the stable pipeline and the next pipeline to finish, prepare the announcement mail for spot-announce
• both the stable and next pipelines will trigger builds of spot-web project, but one build will create the main website, and the other will create the development one. The next pipeline also trigger a build of the spot-sandbox image. 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
• 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