This repo uses semantic versions. Please keep this in mind when choosing version numbers.
-
Alert others you are releasing
There should be no commits made to master while the release is in progress (about 10 minutes). Before you start a release, alert others on gitter so that they don't accidentally merge anything. If they do, and the build fails because of that, you'll have to recreate the release tag described below.
-
Push a git tag
The tag should be of the format
release-N.M.L
, for examplerelease-3.7.1
. -
Wait for CircleCI
This part is controlled by
build-support/publish-stable.sh
. It creates a bunch of new commits, bumps the version, publishes artifacts, and syncs to Maven Central. https://circleci.com/gh/openzipkin/zipkin-gcp
Credentials of various kind are needed for the release process to work. If you notice something failing due to unauthorized, re-save them as environment variables.
The license plugin verifies license headers of files include a copyright notice indicating the years a file was affected. This information is taken from git history. There's a once-a-year problem with files that include version numbers (pom.xml). When a release tag is made, it increments version numbers, then commits them to git. On the first release of the year, further commands will fail due to the version increments invalidating the copyright statement. The way to sort this out is the following:
Before you do the first release of the year, move the SNAPSHOT version back and forth from whatever the current is. In-between, re-apply the licenses.
$ ./mvnw versions:set -DnewVersion=1.3.3-SNAPSHOT -DgenerateBackupPoms=false
$ ./mvnw com.mycila:license-maven-plugin:format
$ ./mvnw versions:set -DnewVersion=1.3.2-SNAPSHOT -DgenerateBackupPoms=false
$ git commit -am"Adjusts copyright headers for this year"