-
Notifications
You must be signed in to change notification settings - Fork 993
Releasing Micrometer
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.
-
See the deploy script used to publish artifacts
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
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.
The CI workflow will go through the steps of building, testing, and publishing the artifacts for the version.
If the previous step succeeded, artifacts are published to Maven Central but they might need time to be browsable and searchable.
Go to the milestones and close the one that belongs to the release, this is also a good time to create a new one.
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.
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.
Knowing these details shouldn’t be necessary for successfully making releases, but if interested you can check them.
The project version is determined at build time by the nebula-release-plugin.
Publishing of the artifacts is handled by the Nebula Publishing Plugin and the Gradle Nexus Publish Plugin