Release plan for Gerrit v3.4

Change-Id: I9d04246f21fbc68aaad56de44006b9e412bb3b80
diff --git a/_posts/2021-03-16-gerrit-3.4-release-plan.md b/_posts/2021-03-16-gerrit-3.4-release-plan.md
new file mode 100644
index 0000000..f72b1a9
--- /dev/null
+++ b/_posts/2021-03-16-gerrit-3.4-release-plan.md
@@ -0,0 +1,110 @@
+---
+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.