Skip to content

Latest commit

 

History

History
61 lines (37 loc) · 2.62 KB

RELEASE.md

File metadata and controls

61 lines (37 loc) · 2.62 KB
Raw

Branch management and versioning strategy

We use Semantic Versioning.

We maintain a separate branch for each minor release, named release-<major>.<minor>, e.g. release-1.1, release-2.0.

The usual flow is to merge new features and changes into the main branch and to merge bug fixes into the latest release branch. Bug fixes are then merged into main from the latest release branch. The main branch should always contain all commits from the latest release branch.

If a bug fix got accidentally merged into main, cherry-pick commits have to be created in the latest release branch, which then have to be merged back into main. Try to avoid that situation.

Maintaining the release branches for older minor releases happens on a best effort basis.

Prepare your release

For a new major or minor release, work from the main branch. For a patch release, work in the branch of the minor release you want to patch (e.g. release-1.21 if you're releasing v1.21.4).

Bump the version in the VERSION file in the root of the repository.

A number of files have to be re-generated, this is automated with the following make target:

make generate

Now that all version information has been updated, an entry for the new version can be added to the CHANGELOG.md file.

Entries in the CHANGELOG.md are meant to be in this order:

  • [CHANGE]
  • [FEATURE]
  • [ENHANCEMENT]
  • [BUGFIX]

Create a PR for the changes to be reviewed.

Publish the new release

For new minor and major releases, create the release-<major>.<minor> branch starting at the PR merge commit. Push the branch to the remote repository with

git push origin release-<major>.<minor>

From now on, all work happens on the release-<major>.<minor> branch.

Tag the new release with a tag named v<major>.<minor>.<patch>, e.g. v2.1.3. Note the v prefix.

tag="v$(< VERSION)"
git tag -s "${tag}" -m "${tag}"
git push origin "${tag}""

Signed tag with a GPG key is appreciated, but in case you can't add a GPG key to your Github account using the following procedure, you can replace the -s flag by -a flag of the git tag command to only annotate the tag without signing.

Our CI pipeline will automatically push the container images to docker.io

Go to https://github.com/kubegems/kubegems/releases/new, associate the new release with the before pushed tag, paste in changes made to CHANGELOG.md and click "Publish release".

For patch releases, submit a pull request to merge back the release branch into the main branch.