This page describes the release process and the currently planned schedule for upcoming releases as well as the respective release shepherd. Release shepherds are chosen on a voluntary basis.
Release cadence of first pre-releases being cut is 6 weeks.
|release series||date of first pre-release (year-month-day)||release shepherd|
|v2.4||2018-09-06||Goutham Veeramachaneni (GitHub: @gouthamve)|
|v2.5||2018-10-24||Frederic Branczyk (GitHub: @brancz)|
|v2.6||2018-12-05||Simon Pasquier (GitHub: @simonpasquier)|
|v2.7||2019-01-16||Goutham Veeramachaneni (GitHub: @gouthamve)|
|v2.8||2019-02-27||Ganesh Vernekar (GitHub: @codesome)|
|v2.9||2019-04-10||Brian Brazil (GitHub: @brian-brazil)|
|v2.10||2019-05-22||Björn Rabenstein (GitHub: @beorn7)|
|v2.11||2019-07-03||Frederic Branczyk (GitHub: @brancz)|
|v2.12||2019-08-14||Julius Volz (GitHub: @juliusv)|
|v2.13||2019-09-25||Krasi Georgiev (GitHub: @krasi-georgiev)|
|v2.14||2019-11-06||Chris Marchbanks (GitHub: @csmarchbanks)|
|v2.15||2019-12-18||Bartek Plotka (GitHub: @bwplotka)|
|v2.16||2020-01-29||searching for volunteer|
If you are interested in volunteering please create a pull request against the prometheus/prometheus repository and propose yourself for the release series of your choice.
The release shepherd is responsible for the entire release series of a minor release, meaning all pre- and patch releases of a minor release. The process formally starts with the initial pre-release, but some preparations should be done a few days in advance.
-rc.0) and creates a new branch called
release-<major>.<minor>starting at the commit tagged for the pre-release. In general, a pre-release is considered a release candidate (that’s what
rcstands for) and should therefore not contain any known bugs that are planned to be fixed in the final release.
See the next section for details on cutting an individual release.
These instructions are currently valid for the Prometheus server, i.e. the prometheus/prometheus repository. Applicability to other Prometheus repositories depends on the current state of each repository. We aspire to unify the release procedures as much as possible.
We use Semantic Versioning.
We maintain a separate branch for each minor release, named
The usual flow is to merge new features and changes into the master branch and to merge bug fixes into the latest release branch. Bug fixes are then merged into master from the latest release branch. The master branch should always contain all commits from the latest release branch. As long as master hasn’t deviated from the release branch, new commits can also go to master, followed by merging master back into the release branch.
If a bug fix got accidentally merged into master after non-bug-fix changes in master, the bug-fix commits have to be cherry-picked into the release branch, which then have to be merged back into master. Try to avoid that situation.
Maintaining the release branches for older minor releases happens on a best effort basis.
For a patch release, work in the branch of the minor release you want to patch.
For a new major or minor release, create the corresponding release branch based on the master branch.
Bump the version in the
VERSION file and update
CHANGELOG.md. Do this in a proper PR pointing to the release branch as this gives others the opportunity to chime in on the release in general and on the addition to the changelog in particular.
CHANGELOG.md should only document changes relevant to users of Prometheus, 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.
Entries in the
CHANGELOG.md are meant to be in this order:
Tag the new release with a tag named
v2.1.3. Note the
You can do the tagging on the commandline:
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 and Circle CI will draft the GitHub release using the
Now all you can do is to wait for tarballs to be uploaded to the Github release and the container images to be pushed to the Docker Hub and Quay.io. Once that has happened, click Publish release, which will make the release publicly visible and create a GitHub notification.
If the release has happened in the latest release branch, merge the changes into master.
To update the docs, a PR needs to be created to
prometheus/docs. See this PR for inspiration (note: only actually merge this for final releases, not for pre-releases like a release candidate).
Once the binaries have been uploaded, announce the release on
email@example.com. (Please do not use
firstname.lastname@example.org for announcements anymore.) Check out previous announcement mails for inspiration.
The following changes to the above procedures apply:
-rc.0to the version (with the corresponding changes to the tag name, the release name etc.).
CHANGELOG.md, but when you cut the final release later, merge all the changes from the pre-releases into the one final update.
x.y.zbeing the latest stable patch release of the previous minor release series.