blob: 6115a5e8fbbb90bc599825ab8243e1ec55f62c47 [file] [log] [blame] [view]
---
title: "Release Plan for Gerrit 3.7"
tags: news
keywords: news
permalink: 2022-09-29-gerrit-3.7-release-plan.html
summary: "Release Plan for Gerrit 3.7"
hide_sidebar: true
hide_navtoggle: true
toc: true
---
## High Level Release Plan
| Date | Activity |
|-----------|----------------------------------------------------|
| Sep 30 | Create stable-3.7 branch, Release '3.7.0-rc0' |
| Oct 7 | Release `3.7.0-rc1` |
| Oct 14 | Release `3.7.0-rc2` |
| Oct 21 | Release `3.7.0-rc3` - Feature freeze deadline |
| Oct 28 | Release `3.7.0-rc4` |
| Nov 4 | Release `3.7.0-rc5` |
| Nov 7-9 | Gerrit Hackathon |
| Nov 9 | Final release of `3.7.0` |
| Nov 10-11 | [Gerrit User Summit 2022](https://www.eventbrite.com/e/gerrit-user-summit-2022-tickets-424995963367) |
## Moving to Discord
The Gerrit Code Review community has moved to [Discord](https://discord.com/invite/HkGbBJHYbY)
and the Gerrit v3.7 release uses a dedicated channel
[`gerrit-3_7-release`](https://discord.com/channels/775374026587373568/1022856831535689838)
for the coordination and collaboration on the all the activities associated with
the release.
## 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.
## Gerrit Hackathon
The Gerrit hackathon is planned during the release week, sponsored and hosted by [GerritForge Ltd](https://www.gerritforge.com)
in [London](https://www.eventbrite.com/e/gerrit-user-summit-2022-tickets-424995963367).
We also encourage all the [JGit contributors and committers](https://projects.eclipse.org/projects/technology.jgit/who)
to join the event.
We will also ask the community members to allocate some of their time during the
hackathon 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.
> NOTE: for all of those who cannot travel or is still blocked by travelling restrictions
> [GerritForge](https://www.gerritforge.com) will setup a remote collaboration channel
> where anyone around the world could join the hackathon remotely.
## 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.7, particularly with medium to large sized projects and in a
multi-primary setup.
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 be pointed to the stable-3.7 branch and run on a daily basis.
## End of Life for Gerrit 3.4.x
Per the support policy mentioned on the
[project homepage](https://www.gerritcodereview.com/support.html#supported-versions),
after 3.7.0 is released 3.4.x will reach end of life and will no longer be
actively supported, which also means that the CI will drop the support for builds
and validations with Java 8.
Support for 3.5.x and 3.6.x will continue as usual.
Users of 3.4.x or earlier are recommended to upgrade to one of these versions.