Back to developer page.

Release Workflow

To make a release you need an exported $DOWNWARD_CONTAINER_REPO environment variable pointing to a local clone of the Github repository for the Fast Downward images. Assuming we want to create the 19.06 release, these are the steps we would follow:

1. Make sure that all buildbots are green.
2. Make sure that you are on the revision you want to release and that the working directory is clean.

3. Make sure both the changelog (see ../ChangelogFormat) and the list of contributors and copyright years (in the README.md file) are up to date and committed. Make sure the changelog includes the line giving the date of the release.

4. Update version number and create branches, tags and recipe files by running the prepare-release.sh script.

   • ./misc/release/prepare-release.sh 19.06.0

5. Verify the following manually:

   1. The fast-downward-19.06.0.tar.gz tarball created in the previous step contains the appropriate files.

   2. Branches and tags in the main repository were created as expected.

   3. A new commit was created in the Git repository at $DOWNWARD_CONTAINER_REPO with the right recipe files and changes.

6. Push all changes.

   • hg push

7. Build the Docker image and push it to the Docker Hub. Note that we build the 19.06 Docker image, not 19.06.0.

   • ./misc/release/push-docker.sh 19.06

8. Push the commmit in the images repository that was automatically created by prepare-release.sh. This should automatically trigger a build of the Singularity image in the Singularity Hub servers.

   • git -C $DOWNWARD_CONTAINER_REPO push

     When we did the 19.06 release, it was not clear if the automatic triggering of the Singularity builds worked or not, so we triggered them manually on Singularity hub (after very little waiting). Watch this in future releases and possibly update this documentation.

9. Create a Wiki page for the release. We suggest starting from a copy of the page for the last release.

   1. Update the date and release version name.
   2. Update the changelog.
   3. Upload the tarball as an attachment to the page.

   4. Upload the Vagrant file created by the prepare-release.sh script as an attachment to the page.

   5. Create a link in Releases to the page of the new release.

10. Send an announcement e-mail to the Fast Downward list including changelog information.

Bugfix Releases

For a bugfix release, the prepare-release.sh script must be run while you are at the tip of the existing release branch. Otherwise, the script transparently handles the differences in the workflow for bugfix releases, so you should be able to apply the above steps with no change, except for the Wiki update. For a bugfix release such as 19.06.1, we do not create a new wiki page, but reuse the major release page (19.06). So we do not change Releases at all, but update Releases/19.06 as follows:

1. Change the title from Fast Downward 19.06 to Fast Downward 19.06.1.

2. Add a line like "Fast Downward 19.06.1 was released on July 33, 2019" below the existing line, leaving the old release date information in place.
3. Update the source tarball link and upload the new tarball. Don't delete the old tarball, just don't link it from anywhere in the page.
4. No need to update the Docker / Singularity / Vagrantfile links: we will at all times keep one single version of these releases, the latest in the 19.06.X family.
5. No need to change the "Referencing Fast Downward 19.06" section.

6. For the changelog section, keep the section title "Changes in Fast Downward 19.06" and the contents, but add the new entries for the bugfix release. Clearly mark which changes belong to 19.06 and which belong to 19.06.1. See ../ChangelogFormat.