Creating a new release produces the following artifacts:
- Binaries (stored in the
cni-plugins-<VERSION>.tgzbinary (copy of amd64 platform binary)
sha512files for the above files.
- 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
- 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
gois 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.
- Make sure you are on the master branch and don’t have any local uncommitted changes.
- Create a signed tag for the release
git tag -s $VERSION(Ensure that GPG keys are created and added to GitHub)
- Run the release script from the root of the repository
- The script requires Docker and ensures that a consistent environment is used.
- The artifacts will now be present in the
- Test these binaries according to the test plan.
- Push the tag to git
git push origin <TAG>
- Create a release on Github, using the tag which was just pushed.
- Attach all the artifacts from the release directory.
- Add the release note to the release.
- Announce the release on at least the CNI mailing, IRC and Slack.