_posts/2021-03-16-gerrit-3.4-release-plan.md - homepage - Git at Google

 ---
 title: "Release Plan for Gerrit 3.4"
 tags: news
 keywords: news
 permalink: 2021-03-16-gerrit-3.4-release-plan.html
 summary: "Release Plan for Gerrit 3.4"
 hide_sidebar: true
 hide_navtoggle: true
 toc: true
 ---

 ## High Level Release Plan

 | Date      | Activity                                           |
 |-----------|----------------------------------------------------|
 | Apr 5     | Create stable-3.4 branch, Release '3.4.0-rc0'      |
 | Apr 12    | Release `3.4.0-rc1`                                |
 | Apr 19    | Release `3.4.0-rc2`                                |
 | Apr 26    | Release `3.4.0-rc3`                                |
 | May 3     | Release `3.4.0-rc4`                                |
 | May 3-7   | Extra E2E testing week                             |
 | May 10-14 | "Release week" (see below)                         |
 | May 17    | Final release of `3.4.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 strongly discouraged on the stable branch
 as it may compromise the stability of the release.

 After `rc3` only 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 spring 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" (10-14 May) 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 and USA time-zones, and we will
 also ask Matthias Sohn or anyone else from the JGit community to be available to
 help with JGit related issues.

 ## End-to-end Testing

 We plan to use the
 [Gatling e2e test framework for Git](https://gerrit-review.googlesource.com/Documentation/dev-e2e-tests.html),
 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](https://gerrit.googlesource.com/aws-gerrit)
 templates.

 [GerritForge](https://www.gerritforge.com) has also offered its own AWS infrastructure to test the
 scalability of Gerrit v3.4, particularly with medium to large sized projects.
 The [Gerrit-CI](https://gerrit-ci.gerritforge.com) has also an automated
 [aws-gerrit pipeline](https://gerrit-ci.gerritforge.com/job/gatling-gerrit-test/)
 that will pointed to the stable-3.4 branch and run on a daily basis.

 ## End of Life for Gerrit 3.1.x

 Per the support policy mentioned on the
 [project homepage](https://www.gerritcodereview.com/support.html#supported-versions),
 after 3.4.0 is released 3.1.x will reach end of life and will no longer be
 actively supported.

 Support for 3.3.x and 3.2.x will continue as usual, 2.16.x may have additional ad-hoc
 releases for issues related to the migration to NoteDb.
 Users of 3.1.x or earlier are recommended to upgrade to one of these versions.

 ## Java

 ### Java 11 official language level

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

 From the [statistics of the latest Gerrit v3.3.x](https://www.gerritcodereview.com/2021-03-09-esc-minutes.html#gerrit-v33-and-double-release-on-java-8)
 only 0.1% of the installations are left on Java 8.

 ### Java 8 compatibility

 __NOTE:This will be the last version with a Java 8 compatible code-base!__

 Although the official releases will be with Java 11 language level the
 code-base of stable-3.4 will be validated against both Java 8 and Java 11,
 thus it will still be possible to build stable-3.4 with Java 8.

 We are aware that a number of companies still rely on Java 8, we have
 therefore opted to keep the code-base of stable-3.4 Java 8 compatible.
 However, we are planning to, at some time prior to the release of v3.5, drop Java 8
 compatibility on the master branch.
	---
	title: "Release Plan for Gerrit 3.4"
	tags: news
	keywords: news
	permalink: 2021-03-16-gerrit-3.4-release-plan.html
	summary: "Release Plan for Gerrit 3.4"
	hide_sidebar: true
	hide_navtoggle: true
	toc: true
	---

	## High Level Release Plan

	\| Date \| Activity \|
	\|-----------\|----------------------------------------------------\|
	\| Apr 5 \| Create stable-3.4 branch, Release '3.4.0-rc0' \|
	\| Apr 12 \| Release `3.4.0-rc1` \|
	\| Apr 19 \| Release `3.4.0-rc2` \|
	\| Apr 26 \| Release `3.4.0-rc3` \|
	\| May 3 \| Release `3.4.0-rc4` \|
	\| May 3-7 \| Extra E2E testing week \|
	\| May 10-14 \| "Release week" (see below) \|
	\| May 17 \| Final release of `3.4.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 strongly discouraged on the stable branch
	as it may compromise the stability of the release.

	After `rc3` only 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 spring 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" (10-14 May) 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 and USA time-zones, and we will
	also ask Matthias Sohn or anyone else from the JGit community to be available to
	help with JGit related issues.

	## End-to-end Testing

	We plan to use the
	[Gatling e2e test framework for Git](https://gerrit-review.googlesource.com/Documentation/dev-e2e-tests.html),
	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](https://gerrit.googlesource.com/aws-gerrit)
	templates.

	[GerritForge](https://www.gerritforge.com) has also offered its own AWS infrastructure to test the
	scalability of Gerrit v3.4, particularly with medium to large sized projects.
	The [Gerrit-CI](https://gerrit-ci.gerritforge.com) has also an automated
	[aws-gerrit pipeline](https://gerrit-ci.gerritforge.com/job/gatling-gerrit-test/)
	that will pointed to the stable-3.4 branch and run on a daily basis.

	## End of Life for Gerrit 3.1.x

	Per the support policy mentioned on the
	[project homepage](https://www.gerritcodereview.com/support.html#supported-versions),
	after 3.4.0 is released 3.1.x will reach end of life and will no longer be
	actively supported.

	Support for 3.3.x and 3.2.x will continue as usual, 2.16.x may have additional ad-hoc
	releases for issues related to the migration to NoteDb.
	Users of 3.1.x or earlier are recommended to upgrade to one of these versions.

	## Java

	### Java 11 official language level

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

	From the [statistics of the latest Gerrit v3.3.x](https://www.gerritcodereview.com/2021-03-09-esc-minutes.html#gerrit-v33-and-double-release-on-java-8)
	only 0.1% of the installations are left on Java 8.

	### Java 8 compatibility

	__NOTE:This will be the last version with a Java 8 compatible code-base!__

	Although the official releases will be with Java 11 language level the
	code-base of stable-3.4 will be validated against both Java 8 and Java 11,
	thus it will still be possible to build stable-3.4 with Java 8.

	We are aware that a number of companies still rely on Java 8, we have
	therefore opted to keep the code-base of stable-3.4 Java 8 compatible.
	However, we are planning to, at some time prior to the release of v3.5, drop Java 8
	compatibility on the master branch.