Skip to content
This repository has been archived by the owner on Jun 20, 2024. It is now read-only.

Release Process

Jump to bottom
Matthias Radestock edited this page Jun 21, 2015 · 12 revisions

Prerequisites

  • Prepare release notes that will go on GitHub
  • Install github.com/aktau/github-release (and up-to-date versions of git, go, etc.)
  • Create a github token for github-release; set and export $GITHUB_TOKEN with this value.
  • Update all dependencies with make update

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
  • commit it, e.g. git commit -m "Add release 0.7.1" CHANGELOG.md"
  • 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.

Now go to https://github.com/weaveworks/weave/releases and edit the release to include the release notes you prepared earlier.

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.
Clone this wiki locally