Releases

What to do know before cutting a release

While prometheus/common does not have a formal release process. We strongly encourage you follow these steps:

1. Scan the list of available issues / PRs and make sure that You attempt to merge any pull requests that appear to be ready or almost ready
2. Notify the maintainers listed as part of MANTAINERS.md that you're going to do a release.

With those steps done, you can proceed to cut a release.

How to cut an individual release

There is no automated process for cutting a release in prometheus/common. The primary trigger for announcing a release is pushing a new version tag.

NOTE: As soon as a new tag is created, many downstream projects will automatically create pull requests to update their dependency of prom/common. Make sure the release is ready to go, with an updated changelog including notices of any breaking changes, before pushing a new tag.

Here are the basic steps:

1. Update VERSION, applying the next logical version number, without any v prefix (e.g. 0.53.0).
2. Update CHANGELOG.md, applying the new version number (this time including the v prefix, e.g. v0.53.0) and date to the changes listed under ``## main / unreleased`, and commit those changes to the main branch.
3. Use GitHub's release feature via this link to apply a new tag. The tag name must be prefixed with a v e.g. v0.53.0 and then use the “Generate release notes” button to generate the release notes automagically ✨. No need to create a discussion or mark it a pre-release, please do make sure it is marked as the latest release.

Versioning strategy

We aim to adhere to Semantic Versioning as much as possible. For example, patch version (e.g. v0.0.x) releases should contain bugfixes only and any sort of major or minor version bump should be a minor or major release respectively.