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 20.06 release, these are the steps we would follow:

  1. TODO: when making the next release, do not forget to include information on supported software; see ../Requirements

  2. Make sure that all Github actions are green.
  3. Make sure that you are on the revision you want to release.
  4. Make sure that the list of contributors and copyright years in the README.md file are up to date.

  5. Make sure the changelog (see ../ChangelogFormat) is up to date and committed. In particular:

    1. Make sure the changelog includes the line giving the date of the release.
    2. Replace the section title ## Changes since the last release with something like ## Fast Downward 20.06.

  6. Make sure that the working directory is clean and that any last-minute changes done following the above steps are commited.
  7. Update version number and create branches, tags and recipe files by running the prepare-release.sh script.

    • ./misc/releases/prepare-release.sh 20.06.0
  8. Verify the following manually:
    1. The fast-downward-20.06.0.tar.gz tarball created in the previous step contains the appropriate files.

    2. Branches and tags were created as expected.
    3. A new commit was created with the right recipe files and version changes.
  9. Push all changes.
    • git push --all
      git push --tags
  10. Build the Docker image and push it to the Docker Hub. Note that we build the 20.06 Docker image, not 20.06.0. Under normal conditions, Docker needs root rights, and the script needs an environment variable that points to a directory containing the SoPlex archive in the correct version.

    • sudo DOWNWARD_LP_INSTALLERS=/path/to/dir/with/installer/ ./misc/releases/push-docker.sh 20.06
  11. Trigger a build of the Singularity image in the Singularity Hub servers.
    • /!\ Automated builds don't currently work (as of 19.12), they have to be triggered manually. Only malte can do this, as the Singularity hub collection "aibasel/downward" is tied to his github account. Unfortunately there is no way of allowing more than one github user access to a collection, it is always tied to an individual account on Singularity hub even if the repository is owned by an organization. In the future, we might try to get the automated builds to work, which probably requires setting up some webhooks or similar on github.

  12. Add a new empty section ## Changes since the last release to the changelog to prepare the changelog section for the next release. Commit and push.

  13. 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.

    6. Make sure the necessary acknowledgements and links are included for SoPlex.

  14. Create a new release on github ( /!\ We consider moving more of the release information to Github. See issue975):

    1. On https://github.com/aibasel/downward/releases click on "Draft new release"

    2. Set Tag to release-20.06.0, Release Title to 20.06, and Description to For information about this release, please visit the [Fast Downward wiki](http://www.fast-downward.org/Releases/20.06).

    3. Click on Publish Release

  15. /!\ In the December 2020 release, remove the read-only repository hg.fast-downward.org and all traces to it (including this point). First check that this is still the current plan.

  16. 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 20.06.1, we do not create a new wiki page, but reuse the major release page (20.06). So we do not change Releases at all, but update Releases/20.06 as follows:

  1. Change the title from Fast Downward 20.06 to Fast Downward 20.06.1.

  2. Add a line like "Fast Downward 20.06.1 was released on July 33, 2020" 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 20.06.X family.
  5. No need to change the "Referencing Fast Downward 20.06" section.
  6. For the changelog section, keep the section title "Changes in Fast Downward 20.06" and the contents, but add the new entries for the bugfix release. Clearly mark which changes belong to 20.06 and which belong to 20.06.1. See ../ChangelogFormat.

FastDownward: ForDevelopers/ReleaseWorkflow (last edited 2021-03-19 15:53:40 by FlorianPommerening)