The release process is pretty straightforward:

Pick a version number

The release number uses a major.minor version format, and should just be numbers. If there‘s a major feature or a breaking change, don’t be shy about bumping the major number: lots of people have a strong belief in SemVer and it would be a pity to let that faith down.

Set up a tracking issue in GitHub

This isn‘t strictly necessary, but it’s polite since it allows us to coordinate the work that we need to complete for the next release.

Make sure all dependencies are up to date

Check the bazel_dep entries and the maven.install (named rules_jvm_external_deps) in MODULE.bazel and make sure that our dependencies are the most recent versions. If they're not, create a PR to update them, and land the change.

Update the MODULE.bazel file to reflect the latest changes

Check that the version parameter in the module declaration is the same as the version number of the release you're about to push.

You may well need to create a PR to update this too.

Tag the release in git and push the tag

The tag format is just the release number (eg. 10.5) without any additional prefixes or suffixes. We use a major.minor version format.

git switch master
git pull
git tag XX.YY
git push --tags

Create a draft entry in the GitHub releases.

I like to copy the previous release, and then edit it. There‘s a handy button in the UI that will generate some release notes. Use it, then edit the values it gives you. The release notes should include user visible changes and all commits by people who aren’t core committers. Bug fixes and little tweaks the core committers have made can be omitted if you don‘t think they’re particularly noteworthy.

Name the draft release after the version you've picked.

Create an archive of the release, and add as an asset

GitHub periodically break how archives are created. To avoid this, package the current release, and upload it as an asset to your draft release.

This asset must be uploaded before publishing the release because the BCR publishing workflow downloads it when the release is published.

You can use git archive --format=tar --prefix=rules_jvm_external-${TAG}/ ${TAG} | gzip > rules_jvm_external-{TAG}.tar.gz to generate the archive.

Prepare the upload to the BCR

This step is now automated by the .github/workflows/publish.yaml workflow, which delegates to bazel-contrib/publish-to-bcr.

When the GitHub release is published, a workflow run will:

  1. Download the release tarball you uploaded in the previous step.
  2. Compute its sha256 integrity hash.
  3. Substitute the templated values in .bcr/*.template.json into modules/rules_jvm_external/<VERSION>/{MODULE.bazel,source.json,presubmit.yml}.
  4. Append the new version to modules/rules_jvm_external/metadata.json.
  5. Open a PR against bazelbuild/bazel-central-registry from the bazel-contrib/bazel-central-registry fork.

A maintainer listed in metadata.json should then approve the BCR PR, and a BCR maintainer will merge it.

If the workflow fails, retry it manually from GitHub Actions > “Publish to BCR” > “Run workflow”, entering the tag name.

If .bcr/presubmit.yml needs to change for a release, such as for a new Bazel version matrix, edit it on master before tagging. The workflow uses whatever is committed at the tag.

Publish the release

Press the magic buttons in the GitHub UI. This starts the BCR workflow described above.