This page describes the release cadence and process for Thanos project.
NOTE: As Semantic Versioning states all 0.y.z releases can contain breaking changes in API (flags, grpc API, any backward compatibility)
We aim for regular and strict one release per 6 weeks. 6 weeks is counter from first release candidate to another. This means that there is no code freeze or anything like that. We plan to stick to the exact 6 weeks, so there is no rush into being within release (except bug fixes).
No feature should block release.
Additionally we (obviously) aim for master
branch being stable.
We will choose a release shepherd for each minor release.
Release shepherd responsibilities:
Process of releasing a minor Thanos version:
v<major>.<minor+1>.0-rc.0
v<major>.<minor>.0
v<major>.<minor>.0-rc.++
Go to step 2.release-xxx
branch.release-<major>.<minor>
that will start minor release branch and prepare changes to cut release.For release candidate just reuse same branch and rebase it on every candidate until the actual release happens.
Note that CHANGELOG.md
should only document changes relevant to users of Thanos, including external API changes, performance improvements, and new features. Do not document changes of internal interfaces, code refactorings and clean-ups, changes to the build process, etc. People interested in these are asked to refer to the git history. Format is described in CHANGELOG.md
.
The whole release from release candidate rc.0
to actual release should have exactly the same section. We don’t separate what have changed between release candidates.
Double check backward compatibility:
v1+.y.z
, double check if none of the changes break API compatibility. This should be done in PR review process, but double check is good to have.v0.y.z
, document all incompatibilities in changelog.After review, merge the PR and immediately after this tag a version:
$ tag=x.y.z
$ git tag -s "v${tag}" -m "v${tag}"
$ git push origin "v${tag}"
Signing a 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.
Once a tag is created, the release process through CircleCI will be triggered for this tag.
You must create a Github Release using the UI for this tag, as otherwise CircleCI will not be able to upload tarballs for this tag. Also, you must create the Github Release using a Github user that has granted access rights to CircleCI. List of maintainers is available here
Go to the releases page of the project, click on the Draft a new release
button and select the tag you just pushed. Describe release and post relevant entry from changelog. Click Save draft
rather than Publish release
at this time. (This will prevent the release being visible before it has got the binaries attached to it.)
Once tarballs are published on release page, you can click Publish
and release is complete.
Announce #thanos
slack channel.
We use Semantic Versioning.
NOTE: We have a separate branch for each minor release, named release-<major>.<minor>
, e.g. release-0.1
, release-0.2
. but they are NOT maintained as we don’t have major version yet.
The following changes to the above procedures apply:
-rc.0
to the version (with the corresponding changes to the tag name, the release name etc.).This is a pre-release
box when drafting the release in the Github UI.CHANGELOG.md
, but when you cut the final release later, merge all the changes from the pre-releases into the one final update.