Release Process

An issue is proposing a new release with a changelog since the last release
All OWNERS must LGTM this release
An OWNER runs and inserts the changelog and pushes the tag with git push $VERSION
The release issue is closed
An announcement email is sent to kubernetes-dev@googlegroups.com with the subject [ANNOUNCE] kops $VERSION is released

We maintain a release-1.4 branch for kops 1.4.X, release-1.5 for kops 1.5.Xetc.

is where development happens. We create new branches from master as anew kops version is released, or in preparation for a new release. As we arepreparing for a new kubernetes release, we will try to advance the master branchto focus on the new functionality, and start cherry-picking back more selectivelyto the release branches only as needed.

Generally we don’t encourage users to run older kops versions, or olderbranches, because newer versions of kops should remain compatible with olderversions of Kubernetes.

Releases should be done from the release-1.X branch. The tags should be madeon the release branches.

Update versions

See 1.5.0-alpha4 commit for example

Edit makefile
If updating dns-controller: bump version in Makefile, code, manifests, and tests

git commit -m "Release 1.X.Y

Check builds OK

Push new dns-controller image if needed

Tag new version

Make sure you are on the release branch

make release-tag
git push
git push --tags

Update release branch

For the time being, we are also maintaining a release branch. We push releasedversions to that.

Pull request to master branch (for release commit)

Use shipbot to upload the release:

Compile release notes

e.g.

git log 1.8.0-beta.1..1.8.0-beta.2 --oneline | grep Merge.pull | cut -f 5 -d ' ' | tac  > ~/shipbot/prs

On github

Download release
Validate it
Add notes
Publish it

Update the alpha channel and/or stable channel

Once we are satisfied the release is sound:

Bump the kops recommended version in the alpha channel

Once we are satisfied the release is stable:

Our release process