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.

Stable-Fix

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.

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.:

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.

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:

Upload the Documentation

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

Finalize the Release Notes

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.

Update homepage links

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.

After the release is actually made, you can search in Google Code 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.

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.