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
-
Create a Gerrit
RC0
-
If needed create a Gerrit
RC1
Note
|
You may let in a few features to this release |
-
If needed create a Gerrit
RC2
Note
|
There should be no new features in this release, only bug fixes |
-
Finally create the
stable
release (noRC
)
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.
Create the Actual Release
To create a Gerrit release the following steps have to be done:
Release Subprojects
The subprojects to be released are:
-
gwtjsonrpc
-
gwtorm
-
prolog-cafe
For each subproject do:
-
Check the dependency to the Subproject in the Gerrit parent
pom.xml
:If a
SNAPSHOT
version of the subproject is referenced the subproject needs to be released so that Gerrit can reference a released version of the subproject. -
Update the
id
,bin_sha1
, andsrc_sha1
values in themaven_jar
for the Subproject in/lib/BUCK
to the released version.
Update Versions and Create Release Tag
Before doing the release build the GERRIT_VERSION
in the VERSION
file must be updated, e.g. change if from 2.5-SNAPSHOT
to 2.5
.
In addition the version must be updated in a number of pom.xml files.
To do this run the ./tools/version.sh
script and provide the new
version as parameter, e.g.:
./tools/version.sh 2.5
Commit the changes and create the release tag on the new commit:
git tag -a v2.5
Build Gerrit
-
Build the Gerrit WAR and API JARs
buck build release buck build api_install
-
Sanity check WAR
-
Test the new Gerrit version
Publish the Gerrit Release
Publish the Gerrit WAR (with Core Plugins)
-
Upload the WAR to the Google Cloud Storage
-
go to https://console.developers.google.com/project/164060093628/storage/gerrit-releases/
-
make sure you are signed in with your Gmail account
-
manually upload the Gerrit WAR file by using the
Upload
button
-
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
file and in thepom.xml
files as described in the Update Versions and Create Release Tag section. -
Push the WAR to Maven Central:
buck build war_deploy
-
Push the plugin artifacts to Maven Central:
buck build api_deploy
For troubleshooting, the environment variable
VERBOSE
can be set. This prints out the commands that are executed by the Buck build process:VERBOSE=1 buck build api_deploy
If no artifacts are uploaded, clean the
buck-out
folder and retry:rm -rf buck-out
-
Push the plugin Maven archetypes to Maven Central:
./tools/plugin_archetype_deploy.sh
-
To where the artifacts are uploaded depends on the
GERRIT_VERSION
in theVERSION
file:-
SNAPSHOT versions are directly uploaded into the Sonatype snapshots repository and no further action is needed:
-
Release versions are uploaded into a staging repository in the Sonatype Nexus Server.
-
-
Verify the staging repository
How to do this is described in the Sonatype OSS Maven Repository Usage Guide.
-
Go to the Sonatype Nexus Server and sign in with your Sonatype credentials.
-
Click in the left navigation bar under
Build Promotion
onStaging Repositories
and find thecomgooglegerrit-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-1029Use 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.
WarningReleasing artifacts to Maven Central cannot be undone! -
Find the closed staging repository in the Sonatype Nexus Server, select it and click on
Release
. -
The released artifacts are available in https://oss.sonatype.org/content/repositories/releases/com/google/gerrit/
-
It may take up to 2 hours until the artifacts appear on Maven Central:
-
Push the Stable Branch
-
Create the stable branch
stable-2.5
in thegerrit
project via the Gerrit Web UI or by push. -
Push the commits done on
stable-2.5
torefs/for/stable-2.5
and get them merged
Push the Release Tag
-
Push the new Release Tag
For an
RC
:git push gerrit-review refs/tags/v2.5-rc0:refs/tags/v2.5-rc0
For a final
stable
release:git push gerrit-review refs/tags/v2.5:refs/tags/v2.5
Upload the Documentation
Build the release notes:
make -C ReleaseNotes
-
Upload html files to the storage bucket via
https://cloud.google.com/console
(manual via web browser)-
Documentation html files must be extracted from
buck-out/gen/Documentation/html.zip
-
-
Update Google Code project links
-
Update the documentation link in the
Resources
section of the Description text, and in theLinks
section. -
Add a link to the new release notes in the
News
section of the Description text
Update the Issues
How do the issues get updated? Do you run a script to do this? When do you do it, after the final 2.5 is released?
By hand.
Our current process is an issue should be updated to say Status =
Submitted, FixedIn-2.5
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=2.5” 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, consider including some or all of the following in the email:
-
A link to the release and the release notes (if a final release)
-
A link to the docs
-
Describe the type of release (stable, bug fix, RC)
-
To: Repo and Gerrit Discussion <repo-discuss@googlegroups.com> Subject: Announce: Gerrit 2.2.2.1 (Stable bug fix update) I am pleased to announce Gerrit Code Review 2.2.2.1. Download: http://code.google.com/p/gerrit/downloads/list This release is a stable bug fix release with some documentation updates including a new "Contributing to Gerrit" doc: http://gerrit-documentation.googlecode.com/svn/Documentation/2.2.2/dev-contributing.html To read more about the bug fixes: http://gerrit-documentation.googlecode.com/svn/ReleaseNotes/ReleaseNotes-2.2.2.1.html -Martin
-
Add an entry to the
NEWS
section of the main Gerrit project web page-
Add entry like:
* Jun 14, 2012 - Gerrit 2.4.1 [https://groups.google.com/d/topic/repo-discuss/jHg43gixqzs/discussion Released]
-
Update the new discussion group announcement to be sticky
-
Click on the announcement thread
-
Near the top right, click on options
-
Under options, click the "Display this top first" checkbox
-
and Save
-
Update the previous discussion group announcement to no longer be sticky
-
See above (unclick checkbox)
-
Increase Gerrit Version for Current Development
All new development that is done in the master
branch will be
included in the next Gerrit release. Update the Gerrit version in the
VERSION
file, and plugin archetypes' pom.xml
files. Push the change
for review 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
Part of Gerrit Code Review