Skip to content

Releasing Micrometer

Tommy Ludwig edited this page Jan 11, 2024 · 16 revisions

This page documents the release process for Micrometer and is intended as a reference for Micrometer maintainers.


Git tags in a specific format are how we mark and start the release process. Once tagged, our CI workflow will run for the new tag and perform the release process.

0) Prerequisites

Make all the changes you want before the release:

  • Merge PRs

  • Check if the release milestone (e.g.: 1.0.0) is clean

  • Check if the other backlog milestones (e.g.: 1.x, 1.0.x) do not contain closed issues

  • Make sure that the CI build is passing after these changes

1) Tag a release

A git tag and GitHub release can be made together at https://github.com/micrometer-metrics/micrometer/releases/new.

Make maintenance release tags from the corresponding maintenance branch. For example, a release version 1.1.2 would be tagged as v1.1.2 from the 1.1.x branch.

Release notes can be generated using https://github.com/spring-io/github-changelog-generator. GitHub’s built-in release note generating feature only includes changes made via pull request. Note that since we do not make issues or pull requests for merging changes forward from maintenance branches, you will need to manually combine release notes. For example, if releasing a patch release for 1.8.x and 1.9.x, the changes in 1.8.x will have been merged forward to 1.9.x but the issues will only be marked for the 1.8.x milestone. When generating the 1.9.x release notes, combine the generated release notes for the 1.9.x release with the notes from the 1.8.x release.

2) Wait for build/test/publish

The CI workflow will go through the steps of building, testing, and publishing the artifacts for the version.

3) Check published artifacts

If the previous step succeeded, artifacts are published to Maven Central but they might need time to be browsable and searchable.

4) Close the milestone

Go to the milestones and close the one that belongs to the release, this is also a good time to create a new one.

5) Announce it on Slack and Twitter

6) Publish next snapshot version

If the release was a GA version, run the CI job for the branch of the release line so that a snapshot is published for the next version. This was requested by the Reactor team so they can immediately start testing against the latest snapshots.


Appendix

Prerequisites and setup

To make a release, you need to have privileges to push tags to this repository. Secrets are configured in the CircleCI config. That’s it. The rest is handled by plugins, scripts, and workflows.

Details

Knowing these details shouldn’t be necessary for successfully making releases, but if interested you can check them.

Dynamic version

The project version is determined at build time by the nebula-release-plugin.

Publishing

Publishing of the artifacts is handled by the Nebula Publishing Plugin and the Gradle Nexus Publish Plugin