...
Once the PMC vote for the release has 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 from master, something is horribly wrong, and the release needs to be rechecked.
| Code Block |
|---|
$ git checkout master
$ git branch -d staging/0.9.11
$ git push upstream :staging/0.9.11 |
...
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 format [VERSION], where [VERSION] is the version of the release:
| Code Block |
|---|
$ git tag -m "Release 0.9.11." 0.9.11
$ git push upstream 0.9.11 |
...
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 guacamole-website, which is not part of the release.
Example: the “0.9.10-incubating” tag on guacamole-server
...
The release artifacts and their signatures come from the release candidate which was approved via the VOTE. These artifacts are already present in the SVN dist area under dev/, and need to be moved to the analogous area under release/. This must be done using svn mv, with the directory containing the artifacts and signatures being renamed from [VERSION]-RC[N] to [VERSION] in the process.
| Code Block |
|---|
$ svn mv dev/guacamole/0.9.11-RC1 release/guacamole/0.9.11
$ svn commit -m "Promote Apache Guacamole 0.9.11-RC1 artifacts to 0.9.11 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 example, to build the guacamole/guacamole Docker image for the current release candidate, from within the top-level guacamole-client directory:
| Code Block |
|---|
$ git clean -xfd .
$ sudo docker build -t guacamole/guacamole:0.9.11 .
$ 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:
| Code Block |
|---|
$ sudo docker push guacamole/guacamole:0.9.11
$ 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.
...