Note
 This document is meant primarily for Gerrit maintainers who have been given approval and submit status to the Gerrit projects. Additionally, maintainers should be given owner status to the Gerrit web site.

To make a Gerrit release involves a great deal of complex tasks and it is easy to miss a step so this document should hopefully serve as both a how to for those new to the process and as a checklist for those already familiar with these tasks.

Gerrit Release Type

Here are some guidelines on release approaches depending on the type of release you want to make (stable-fix, stable, rc0, rc1…​).

Stable

A stable release is generally built from the master branch and may need to undergo some stabilization before releasing the final release.

  • Propose the release with any plans/objectives to the mailing list.

  • Release plans usually become a news article to be followed up with.

  • Create a Gerrit rc0.

  • If needed create Gerrit rc1, rc2 and rc3 (one per week, on Mondays or so; see past release plans).

Note
 You may let in a few features to these releases.

  • If needed create a Gerrit rc4.

Note
 There should be no new features in this release, only bug fixes.

  • Finally create the stable release (no rc).

Stable-Fix

stable-fix releases should likely only contain bug fixes and doc updates.

  • Propose the release with any plans/objectives to the mailing list.

  • This type of release does not need any RCs, release when the objectives are met.

Security-Fix

security-fix releases should only contain bug fixes for security issues.

For security issues it is important that they are only announced after fixed versions for all relevant releases have been published. Because of this, security-fix releases can’t be prepared in the public gerrit project.

security-fix releases are prepared in the gerrit-security-fixes project which is only readable by the Gerrit Maintainers. Only after a security-fix release has been published will the commits/tags made in the gerrit-security-fixes project be taken over into the public gerrit project.

Upload the final Release Notes change

Upload a change on the homepage project to:

  • Remove 'In Development' caveat from the relevant section.

  • Add links to the released documentation and the .war file, and make the latest version bold.

The uploaded change is not to be approved yet, but rather act as the release content review thread until it can be finalized.

Upload a change on the homepage project to change the version numbers to the new version.

Update the Issues

Update the issues by hand. There is no script for this.

Our current process is an issue should be updated to say Status = Submitted, FixedIn-$version once the change is submitted, but before the release.

The updated issues are the ones listed in commit messages since the previous version tag. Mention each updated issue in the uploaded change, following the examples from the previous version notes. Add updated issue owners as reviewers of the uploaded change. More reviewers can be added or cc’ed, to further coordinate the final release contents.

Similarly to issues, also mention every noteworthy change done after the previous release. Again, previous notes should be used as template examples.

You may need to split note update changes from the final change that updates the links. This allows non-final update changes to be reviewed and submitted timely. The final (links) change may take more time to complete, as this underlying release process unfolds.

Create the Actual Release

Update Versions and Create Release Tag

Before doing the release build, the GERRIT_VERSION in the version.bzl file must be updated, e.g. change it from $version-SNAPSHOT to $version.

In addition the version must be updated in a number of *_pom.xml files.

To do this run the ./tools/version.py script and provide the new version as parameter, e.g.:

  version=2.15
  ./tools/version.py $version

Commit the changes and create a signed release tag on the new commit:

  git tag -s -m "v$version" "v$version"

If unable to tag, make sure that git is locally configured with your user’s key. These are the macOS instructions but such commands should be portable enough. Setting GPG_TTY this way or similar might also be necessary:

  export GPG_TTY=$(tty)

Tag the plugins:

  git submodule foreach '[ "$sm_path" == "modules/jgit" ] || git tag -s -m "v$version" "v$version"'

Build Gerrit

  • Build the Gerrit WAR, API JARs and documentation:

      bazel build release Documentation:searchfree
  ./tools/maven/api.sh war_install
  ./tools/maven/api.sh install

  • Verify the WAR version:

      java -jar bazel-bin/release.war --version

  • Try upgrading a test site and launching the daemon.

  • Verify the plugin versions:

      java -jar bazel-bin/release.war init --list-plugins

Publish the Gerrit Release

Publish the Gerrit artifacts to Maven Central

  • Make sure you have done the configuration for deploying to Maven Central.

  • Make sure that the version is updated in the version.bzl file and in the *_pom.xml files as described in the Update Versions and Create Release Tag section.

  • Push the WAR to Maven Central:

      ./tools/maven/api.sh war_deploy

  • Push the plugin artifacts to Maven Central:

      ./tools/maven/api.sh deploy

  • To where the artifacts are uploaded depends on the GERRIT_VERSION in the version.bzl file:

  • Verify the staging repository

    • Go to the Sonatype Nexus Server and sign in with your Sonatype credentials.

    • Click on 'Build Promotion' in the left navigation bar under 'Staging Repositories' and find the comgooglegerrit-XXXX staging repository.

    • Verify its content

      While the staging repository is open you can upload further content and also replace uploaded artifacts. If something is wrong with the staging repository you can drop it by selecting it and clicking on Drop.

    • Run Sonatype validations on the staging repository

      Select the staging repository and click on Close. This runs the Sonatype validations on the staging repository. The repository will only be closed if everything is OK. A closed repository cannot be modified anymore, but you may still drop it if you find any issues.

    • Test closed staging repository

      Once a repository is closed you can find the URL to it in the Summary section, e.g. https://oss.sonatype.org/content/repositories/comgooglegerrit-1029.

      Use this URL for further testing of the artifacts in this repository, e.g. to try building a plugin against the plugin API in this repository update the version in the *_pom.xml and configure the repository:

        <repositories>
    <repository>
      <id>gerrit-staging-repository</id>
      <url>https://oss.sonatype.org/content/repositories/comgooglegerrit-1029</url>
    </repository>
  </repositories>

  • Release the staging repository

    How to release a staging repository is described in the Sonatype OSS Maven Repository Usage Guide.

    Warning
    		 Releasing artifacts to Maven Central cannot be undone!

  • [optional]: View download statistics

    • Sign in to the Sonatype Nexus Server.

    • Click on 'Views/Repositories' in the left navigation bar under 'Central Statistics'.

    • Select com.google.gerrit as Project.

Publish the Gerrit WAR to the Google Cloud Storage

Push the Stable Branch

  • Create the stable branch stable-$version in the gerrit project via the Gerrit Web UI or by push.

  • Push the commits done on stable-$version to refs/for/stable-$version and get them merged.

  • Create a change updating the defaultbranch field in the .gitreview to match the branch name created.

Push the Release Tag

Push the new Release Tag:

  git push gerrit-review tag v$version

Push the new Release Tag on the plugins:

  git submodule foreach '[ "$sm_path" == "modules/jgit" ] || git push gerrit-review tag "v$version"'

Publish TypeScript Plugin API

Only applies to major and minor releases! Not required for patch releases.

  • Publish a new version of the npm package @gerritcodereview/typescript-api. See api/README.md for details.

  • The plugins in the stable branch of the minor release and the master branch be changed to use the new API version, see example change

Upload the Documentation

  • Extract the documentation files from the zip file generated from bazel build searchfree: bazel-bin/Documentation/searchfree.zip.

  • Upload the files manually via web browser to the appropriate folder in the gerrit-documentation storage bucket.

Finalize the Release Notes

Submit any previously uploaded notes change on the homepage project.

Update list of supported releases

If you created a new stable release update the list of supported releases in the support page.

Gerrit releases are also listed on the endoflife website. Push a PR to endoflife.date repository to update supported releases in products/gerrit.md. New release tags should be updated automatically by the site’s automation job which uses Dependabot to auto-create PRs for new release tags.

Update the Issues

After the release is actually made, you can search (in Monorail) for Status=Submitted FixedIn=$version and then batch update these changes to say Status=Released. Make sure the pulldown says All Issues because Status=Submitted is considered a closed issue.

Announce on Mailing List

Send an email to the mailing list to announce the release. The content of the announcement email is generated with the release-announcement.py script from the gerrit-release-tools repository, which automatically includes all the necessary links, hash values, and wraps the text in a PGP signature.

For details refer to the documentation in the script’s header, and/or the help text:

  ~/gerrit-release-tools/release-announcement.py --help

Increase Gerrit Version for Current Development

All new development that is done in the master branch will be included in the next Gerrit release. The Gerrit version should be set to the snapshot version for the next release.

Use the version tool to set the version in the version.bzl file:

  ./tools/version.py 2.6-SNAPSHOT

Verify that the changes made by the tool are sane, then commit them, push the change for review on the master branch, and get it merged.

Merge stable into master

After every release, stable should be merged to master to ensure that none of the changes/fixes ever get lost.

  git config merge.summary true
  git checkout master
  git reset --hard origin/master
  git branch -f stable origin/stable
  git merge stable

Bazlets is used by gerrit plugins to simplify build process. To allow the new released version to be used by gerrit plugins, gerrit_api.bzl must reference the new version. Upload a change to bazlets repository with api version upgrade.

Clean up on master

Once you are done with the release, check if there are any code changes in the master branch that were gated on the next release. Mostly, these are feature-deprecations that we were holding off on to have a stable release where the feature is still contained, but marked as deprecated.

See Deprecating features for details.

Part of Gerrit Code Review