|
Size: 4631
Comment: Add reminder about updating contributor list
|
Size: 3388
Comment:
|
| Deletions are marked like this. | Additions are marked like this. |
| Line 5: | Line 5: |
| Let us assume that we want to create the `19.06` release. The steps we'd do are; | To make a release you need a `$DOWNWARD_CONTAINER_REPO` environment variable pointing to a local clone of the [[https://github.com/aibasel/downward|Github repository]] for the Fast Downward images. Assuming we want to create the `19.06` release, these are the steps we would follow: |
| Line 7: | Line 8: |
| 1. Update to the revision we want to release, e.g., `default`. | 1. Make sure that you are on the revision you want to release and that the working directory is clean. 1. 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. 1. Update version number and create branches, tags and recipe files by running the `prepare-release.sh` script. |
| Line 9: | Line 12: |
| hg update default | ./misc/release/prepare-release.sh 19.06.0 |
| Line 11: | Line 14: |
| 1. Collect the changelog information, add it to `CHANGES.md` (see [[../ChangelogFormat]]), and commit {{{ hg commit -m "Update changelog for release 19.06." }}} 1. Update the list of contributors (and copyright years, if applicable) in the main `README.md` file and commit {{{ hg commit -m "Update readme for release 19.06." }}} 1. Create a branch named `release-19.06`, update the version number, and create a tag named `release-19.06.0`. {{{ hg branch release-19.06 hg commit -m "Create branch for release 19.06." misc/set-version.py 19.06.0 hg commit -m "Update version number to 19.06.0." hg tag release-19.06.0 -m "Create release 19.06." }}} 1. Back on the default branch, update version number to `19.06.0+`. {{{ hg update default misc/set-version.py 19.06.0+ hg commit -m "Update version number to 19.06.0+." }}} |
1. Verify manually that the `fast-downward-19.06.0.tar.gz` tarball created in the previous step contains the appropriate files, that branches and tags were created as expected, and that a new commit was created in the Git repository at `$DOWNWARD_CONTAINER_REPO` with the right recipe files and changes. |
| Line 37: | Line 19: |
| 1. Create the tarball | 1. Build the Docker image and push it to the Docker Hub. Note that we build the `19.06` Docker image, not `19.06.0`. |
| Line 39: | Line 21: |
| hg archive -r release-19.06.0 -X .hg_archival.txt -X .hgignore \ -X .hgtags -X .uncrustify.cfg -X bitbucket-pipelines.yml \ -X experiments/ -X misc/ --type tgz fast-downward-19.06.tar.gz |
./misc/release/push-docker.sh 19.06 |
| Line 43: | Line 23: |
| 1. Manually verify that the tarball contains the correct files. 1. Generate the different recipe files for Docker, Singularity and Vagrant. |
1. Go to the `$DOWNWARD_CONTAINER_REPO` directory and push the commmit that was automatically created by `prepare-release.sh`. This should automatically trigger a build of the Singularity image in the Singularity Hub servers. |
| Line 47: | Line 25: |
| misc/release/create-images.py --tag 19.06 }}} 1. Take the generated Dockerfile, put it into a temporary empty directory, and build it. You can remove the directory immediately afterwards as the docker image is stored in your local registry. {{{ # Assuming you are in a temporary directory containing Dockerfile.19.06 only docker build -t aibasel/downward:19.06 -f Dockerfile.19.06 . }}} 1. Login into the Docker Hub with your credentials (you must be part of the `aibasel` organization!), push the image that we just generated and label it as latest. {{{ docker login --username=gfrancesm docker push aibasel/downward:19.06 docker tag aibasel/downward:19.06 aibasel/downward:latest docker push aibasel/downward:latest }}} 1. Clean up created container and all unused docker images. {{{ docker rmi aibasel/downward:19.06 docker image prune -f }}} 1. Once the Docker image is in the Hub, the Singularity image can be built on the Singularity Hub servers. Add all newly-generated recipe files to your local copy of the [[https://github.com/aibasel/downward|Fast Downward containers repository]]. {{{ git add 19.06/Dockerfile.19.06 git add 19.06/Singularity.19.06 git add 19.06/Vagrantfile.19.06 ln -fs 19.06/Dockerfile.19.06 latest/Dockerfile ln -fs 19.06/Singularity.19.06 latest/Singularity ln -fs 19.06/Vagrantfile.19.06 latest/Vagrantfile git add latest git commit -m "Add recipe files for release 19.06." |
cd $DOWNWARD_CONTAINER_REPO |
| Line 82: | Line 32: |
| 1. Upload the Vagrant file created by the `create-images.py` script as an attachment to the page. | 1. Upload the Vagrant file created by the `prepare-release.sh` script as an attachment to the page. |
| Line 89: | Line 39: |
| When we make a bugfix release, e.g., 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: | The `prepare-release.sh` script handles transparently 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: |
| Line 92: | Line 43: |
| 1. Add a line like "Fast Downward 19.06.1 was released on XXX 2019" below the existing line, leaving the old release date information in place. | 1. 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. |
Back to developer page.
Release Workflow
To make a release you need a $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:
- Make sure that you are on the revision you want to release and that the working directory is clean.
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.
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
Verify manually that the fast-downward-19.06.0.tar.gz tarball created in the previous step contains the appropriate files, that branches and tags were created as expected, and that a new commit was created in the Git repository at $DOWNWARD_CONTAINER_REPO with the right recipe files and changes.
- Push all changes.
hg push
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
Go to the $DOWNWARD_CONTAINER_REPO directory and push the commmit that was automatically created by prepare-release.sh. This should automatically trigger a build of the Singularity image in the Singularity Hub servers.
cd $DOWNWARD_CONTAINER_REPO git push
Create a Wiki page for the release. We suggest copying the one from the last releases.
- Update the date and release version name.
- Update the changelog.
- Upload the tarball as an attachment to the page.
Upload the Vagrant file created by the prepare-release.sh script as an attachment to the page.
Create a link in Releases to the page of the new release.
- Send an announcement e-mail to the Fast Downward list including changelog information.
Bugfix Releases
The prepare-release.sh script handles transparently 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:
Change the title from Fast Downward 19.06 to Fast Downward 19.06.1.
- 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.
- 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.
- 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.
- No need to change the "Referencing Fast Downward 19.06" section.
- 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.