Release Process

Releases

The script ./bin/release is used for releasing the weave distributables. This amounts to pushing new images to DockerHub, and creating a GitHub release and uploading the script to it. The release script looks for the most recent tag matching v* to see what it should build.

To prepare a release, you need to

• choose a version number, e.g., 0.7.1 (call it $version)
• add a changelog entry for the new version, at the top of CHANGELOG.md, and commit it
• tag the repo at that point with v$version (e.g., git tag -a -m "Release 0.7.1" v0.7.1)

You can now do

./bin/release build

which will clone the repo into ./releases/v$version/ and build the images. It also injects version strings into the executables and script so they can be recognised.

To publish a release, in the ./releases/v$version/ dir you need to

• move the tag latest_release to the same commit as the version tag; e.g., git tag -af latest_release v0.7.1
• push both the tags to the upstream repo; e.g., git push -f [email protected]:weaveworks/weave latest_release v0.7.1 (NB if you're testing the release process, remember to push to your own github repo)

You can now publish the release with

./bin/release publish

which will do some sanity checks (like making sure there's not already a release for that version), push the docker images, and create the GitHub release.

Trouble

There's a few things that can go wrong.

• If the build is wonky, e.g., the tests don't pass, you can delete the directory in ./releases/, fix whatever it is, move the version tag (which should still be only local) and have another go.
• If the DockerHub pushes fail (which sadly seems to happen a lot), you can just run ./bin/release publish again.
• If it turns out you released the wrong thing, you can delete the release on github and start again; it's the only thing that has to be manually deleted.