Promoting a release candidate to release
- Delete the release branch
- Tag the final version of the release
- Upload final release artifacts
Delete the release branch
Once the PPMC vote and IPMC
vote for the release have passed, the
release branches which were created
previously must be deleted.
Assuming they were properly merged back to
master as release-specific changes
were made, deleting these branches with
git branch -d will succeed without
warnings. If git refuses to delete the branches because commits are missing
master, something is horribly wrong, and the release needs to be
$ git checkout master $ git branch -d staging/0.9.11-incubating $ git push upstream :staging/0.9.11-incubating
Tag the final version of the release
The specific point in the git history that the release was made must be marked
with a new tag, pointing to the exact same commit as the last tagged release
candidate. This tag must be made in the
[VERSION] is the version of the release:
$ git tag -m "Release 0.9.11-incubating." 0.9.11-incubating $ git push upstream 0.9.11-incubating
Just as with release candidates, each repository relevant to the release must
be tagged. This will be every repository that had a release branch (the release
branch having been deleted earlier) and never includes
incubator-guacamole-website, which is not part of the release.
Upload final release artifacts
Artifacts in dist SVN
The release artifacts and their signatures come from the release candidate
which was approved via the various VOTEs. These artifacts are already present
in the SVN dist area under
dev/, and need to be moved to the analogous area
release/. This must be done using
svn mv, with the directory
containing the artifacts and signatures being renamed from
[VERSION] in the process.
$ svn mv dev/incubator/guacamole/0.9.11-incubating-RC1 release/incubator/guacamole/0.9.11-incubating $ svn commit -m "Promote Apache Guacamole 0.9.11-incubating-RC1 artifacts to 0.9.11-incubating release."
Note that, once this has finished, YOU MUST STILL WAIT AT LEAST 24 HOURS TO ALLOW THE MIRRORS TIME TO SYNC before announcing the release.
For the Maven artifacts to become generally available at https://repository.apache.org/, and for those artifacts to be synced with Maven Central, the staging repository created and closed earlier needs to be explicitly released using Apache’s Nexus instance. Doing this involves simply selecting the repository, clicking the “release” button, and typing a reasonable log message noting the release.
Note that it may take a day or so for Maven Central to contain the new artifacts, just like the mirrors, but absence of artifacts from Maven Central does not block announcement of the release as long as they are confirmed to be present on https://repository.apache.org/.
guacamole/guacd images should now be
updated with a new version-specific tag, duplicated to the
latest tag. Since
the images deployed for past release candidates were first cleaned with
git clean, nothing should be actually rebuilt as a consequence of running
docker build unless something has gone wrong and source changes were made
in the absence of an RC.
For example, to build the
guacamole/guacamole Docker image for the current
release candidate, from within the top-level
$ git clean -xfd . $ sudo docker build -t guacamole/guacamole:0.9.11-incubating . $ sudo docker build -t guacamole/guacamole:latest .
Each of the above commands should finish virtually instantaneously, and the hash of the built images should match each other and the previous RC. Assuming all looks well, it should be safe to push the images:
$ sudo docker push guacamole/guacamole:0.9.11-incubating $ sudo docker push guacamole/guacamole:latest
Again, this should finish virtually instantaneously, as no new data will need to be pushed. Docker Hub already has the images/layers from the previous RC builds.