# Release process

## Resulting artifacts
Creating a new release produces the following artifacts:

- Binaries (stored in the `release-<TAG>` directory) :
  - `cni-plugins-<PLATFORM>-<VERSION>.tgz` binaries
  - `cni-plugins-<VERSION>.tgz` binary (copy of amd64 platform binary)
  - `sha1`, `sha256` and `sha512` files for the above files.

## Preparing for a release
1. Releases are performed by maintainers and should usually be discussed and planned at a maintainer meeting.
  - Choose the version number. It should be prefixed with `v`, e.g. `v1.2.3`
  - Take a quick scan through the PRs and issues to make sure there isn't anything crucial that _must_ be in the next release.
  - Create a draft of the release note
  - Discuss the level of testing that's needed and create a test plan if sensible
  - Check what version of `go` is used in the build container, updating it if there's a new stable release.
  - Update the vendor directory and Godeps to pin to the corresponding containernetworking/cni release. Create a PR, makes sure it passes CI and get it merged.

## Creating the release artifacts
1. Make sure you are on the master branch and don't have any local uncommitted changes.
1. Create a signed tag for the release `git tag -s $VERSION` (Ensure that GPG keys are created and added to GitHub)
1. Run the release script from the root of the repository
  - `scripts/release.sh`
  - The script requires Docker and ensures that a consistent environment is used.
  - The artifacts will now be present in the `release-<TAG>` directory.
1. Test these binaries according to the test plan.

## Publishing the release
1. Push the tag to git `git push origin <TAG>`
1. Create a release on Github, using the tag which was just pushed.
1. Attach all the artifacts from the release directory.
1. Add the release note to the release.
1. Announce the release on at least the CNI mailing, IRC and Slack.