-
Notifications
You must be signed in to change notification settings - Fork 1k
Releasing Micrometer
|
Note
|
This is a draft describing the release process we are working towards. |
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
Once all changes for a release have been made and CI builds are passing, start the release process by following the steps below.
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.
The CI workflow will go through the steps of building, testing, and publishing the artifacts for the version.
After the workflow publishes the artifacts to jcenter, it will pause for approval to proceed. Any checks/tests of the release artifacts can be done using the release version and the jcenter repository.
If everything is satisfactory in the previous step, approve the waiting approval job on CircleCI. Then the last job will sync the release artifacts from jcenter to Maven Central.
To make a release, you need to have privileges to push tags to this repository. Secrets are encrypted and the key to decrypt them needs to be configured in the CI. You need privileges on the Micrometer CircleCI to approve the job that blocks the Maven Central sync. 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 spring-release-plugin which extends the nebula-release-plugin.
The publishing of artifacts and versions to Bintray is handled by the spring-bintray-plugin which extends the gradle-bintray-plugin.