High Level Release Plan

Date Activity
September Set Java source/target language level to 11
Oct 25 Create stable-3.5 branch, Release ‘3.5.0-rc0’
Nov 1 Release 3.5.0-rc1
Nov 15 Release 3.5.0-rc2
Nov 16-21 E2E testing week
Nov 22 Release 3.5.0-rc3
Nov 29 Release 3.5.0-rc4
Nov 30 - Dec 05 “Release week” (see below)
Dec 06 Final release of 3.5.0

Change Acceptance Policy for the Stable Branch

We don’t expect that all ongoing feature development will be completed before the stable branch is created, so we will allow the completion of existing features on the stable branch to bring features to completion until rc3.

The development of new features is very rarely accepted on the stable branch as it may compromise the stability of the release.

After rc3 only E2E test and associated bug fixes will be accepted on the stable branch.

We would prefer that bug fixes are pushed for review directly onto the stable branch, rather than onto master to be cherry-picked back. The reason for this is to avoid that the release managers need to spend time manually checking which changes need to be backported, which could result in changes being overlooked.

“Release Week”

The continued emergency with the global outbreak of COVID-19 has made unlikely to have a face-to-face Gerrit Maintainers’ Hackathon in the fall of 2021, where we typically had managed the release with the cooperation of all maintainers.

We will ask the community members to allocate some of their time during the “release and e2e testing week” (16-28 November) to help with finalizing the release:

  • Test the release candidates.
  • Report issues.
  • Triage and troubleshoot incoming bug reports.
  • Make fixes.
  • Do code reviews.
  • Test the latest head of the stable branch.

To expedite reviews of Library-Compliance and frontend changes, we will ask Google to make some members available in the EU time-zone, and we will also ask Matthias Sohn or anyone else from the JGit community to be available to help with JGit related issues.

There is a dedicated private Slack channel for facilitating the communication and coordination of the Gerrit v3.5.0 release. All Gerrit maintainers are part of the channel. Anyone willing to help with the preparation of the release, including other Gerrit contributors, can request to be added to the channel on the repo-discuss mailing list.

End-to-end Testing

We plan to use the Gatling e2e test framework for Git, developed by GerritForge and Ericsson, to test the stability of the release on a production-like setup on AWS automatically provisioned using the aws-gerrit templates.

GerritForge has also offered its own AWS infrastructure to test the scalability of Gerrit v3.5, particularly with medium to large sized projects. The Gerrit-CI has also an automated aws-gerrit pipeline that will be pointed to the stable-3.5 branch and run on a daily basis.

End of Life for Gerrit 3.2.x

Per the support policy mentioned on the project homepage, after 3.5.0 is released 3.2.x will reach end of life and will no longer be actively supported.

Support for 3.4.x and 3.3.x will continue as usual. Users of 3.2.x or earlier are recommended to upgrade to one of these versions.

End of the special status for Gerrit 2.16.x

The ESC has agreed on the meeting in June that the special EOL status of Gerrit v2.16 will end when v3.5 is released.

Java

Java 11 official language level

Gerrit v3.5.x official releases will have Java 11 language level, this means that the officially released gerrit.war won’t start on Java 8.

Java 8 compatibility

Gerrit v3.5.x does not support Java 8: all users will have to upgrade to Java 11 prior to upgrading.

The Gerrit code will be set to Java 11 source-level validation in September 2021, prior to the release cycle of Gerrit v3.5.