docs: introduce Stable Releases. (#9919)

Originally discussed and approved in:
https://bit.ly/envoy-stable-releases

Fixes #7915.

Signed-off-by: Piotr Sikora <[email protected]>

CONTRIBUTING.md

@@ -69,18 +69,6 @@ versioning guidelines:
   it is expected the multi-phase warn-by-default/fail-by-default is sufficient to warn users to move
   away from deprecated features.
 
-# Release cadence
-
-* Currently we are targeting approximately quarterly official releases. We may change this based
-  on customer demand.
-* In general, master is assumed to be release candidate quality at all times for documented
-  features. For undocumented or clearly under development features, use caution or ask about
-  current status when running master. Lyft runs master in production, typically deploying every
-  few days.
-* Note that we currently do not provide binary packages (RPM, etc.). Organizations are expected to
-  build Envoy from source. This may change in the future if we get resources for maintaining
-  packages.
-
 # Submitting a PR
 
 * Fork the repo.

GOVERNANCE.md

@@ -70,16 +70,15 @@ or you can subscribe to the iCal feed [here](https://app.opsgenie.com/webcal/get
 
 ## Cutting a release
 
-* We do releases approximately every 3 months as described in the
-  [release cadence documentation](CONTRIBUTING.md#release-cadence).
-* Decide on the somewhat arbitrary time that a release will occur.
+* We do releases every 3 months, at the end of each quarter, as described in the
+  [release schedule](RELEASES.md#release-schedule).
 * Take a look at open issues tagged with the current release, by
   [searching](https://github.com/envoyproxy/envoy/issues) for
   "is:open is:issue milestone:[current milestone]" and either hold off until
   they are fixed or bump them to the next milestone.
 * Begin marshalling the ongoing PR flow in this repo. Ask maintainers to hold off merging any
-  particularly risky PRs until after the release is tagged. This is because we currently don't use
-  release branches and assume that master is RC quality at all times.
+  particularly risky PRs until after the release is tagged. This is because we aim for master to be
+  at release candidate quality at all times.
 * Do a final check of the [release notes](docs/root/intro/version_history.rst) and make any needed
   corrections.
 * Switch the [VERSION](VERSION) from a "dev" variant to a final variant. E.g., "1.6.0-dev" to
@@ -90,6 +89,8 @@ or you can subscribe to the iCal feed [here](https://app.opsgenie.com/webcal/get
 * Create a [tagged release](https://github.com/envoyproxy/envoy/releases). The release should
   start with "v" and be followed by the version number. E.g., "v1.6.0". **This must match the
   [VERSION](VERSION).**
+* Create a branch from the tagged release, e.g. "release/v1.6". It will be used for the
+  [stable releases](RELEASES.md#stable-releases).
 * Monitor the CircleCI tag build to make sure that the final docker images get pushed along with
   the final docs. The final documentation will end up in the
   [envoyproxy.github.io repository](https://github.com/envoyproxy/envoyproxy.github.io/tree/master/docs/envoy).

RELEASES.md

@@ -0,0 +1,70 @@
+# Release Process
+
+## Active development
+
+Active development is happening on the `master` branch, and a new version is released from it
+at the end of each quarter.
+
+## Stable releases
+
+Stable releases of Envoy include:
+
+* Extended maintenance window (any version released in the last 12 months).
+* Security fixes backported from the `master` branch (including those deemed not worthy
+  of creating a CVE).
+* Stability fixes backported from the `master` branch (anything that can result in a crash,
+  including crashes triggered by a trusted control plane).
+* Bugfixes, deemed worthwhile by the maintainers of stable releases.
+
+### Hand-off
+
+Hand-off to the maintainers of stable releases happens after Envoy maintainers release a new
+version from the `master` branch by creating a `vX.Y.0` tag and a corresponding `release/vX.Y`
+branch, with merge permissions given to the release manager of stable releases, and CI configured
+to execute tests on it.
+
+### Security releases
+
+Critical security fixes are owned by the Envoy security team, which provides fixes for the
+`master` branch, and the latest release branch. Once those fixes are ready, the maintainers
+of stable releases backport them to the remaining supported stable releases.
+
+### Backports
+
+All other security and reliability fixes can be nominated for backporting to stable releases
+by Envoy maintainers, Envoy security team, the change author, or members of the Envoy community
+by adding the `backport/review` or `backport/approved` label (this can be done using [repokitteh]'s
+`/backport` command). Changes nominated by the change author and/or members of the Envoy community
+are evaluated for backporting on a case-by-case basis, and require approval from either the release
+manager of stable release, Envoy maintainers, or Envoy security team. Once approved, those fixes
+are backported from the `master` branch to all supported stable branches by the maintainers of
+stable releases. New stable versions from non-critical security fixes are released on a regular
+schedule, initially aiming for the bi-weekly releases.
+
+### Release management
+
+Release managers of stable releases are responsible for approving and merging backports, tagging
+stable releases and sending announcements about them. This role is rotating on a quarterly basis.
+
+| Quarter |       Release manager        |
+|:-------:|:----------------------------:|
+| 2020 Q1 | Piotr Sikora ([PiotrSikora]) |
+
+## Release schedule
+
+In order to accommodate downstream projects, new Envoy releases are produced on a fixed release
+schedule (at the end of each quarter), with an acceptable delay of up to 2 weeks, with a hard
+deadline of 3 weeks.
+
+| Version |  Expected  |   Actual   | Difference | End of Life |
+|:-------:|:----------:|:----------:|:----------:|:-----------:|
+| 1.12.0  | 2019/09/30 | 2019/10/31 |  +31 days  | 2020/10/31  |
+| 1.13.0  | 2019/12/31 | 2020/01/20 |  +20 days  | 2021/01/20  |
+| 1.14.0  | 2020/03/31 |            |            |             |
+| 1.15.0  | 2020/06/30 |            |            |             |
+| 1.16.0  | 2020/09/30 |            |            |             |
+| 1.17.0  | 2020/12/31 |            |            |             |
+
+
+[repokitteh]: https://github.com/repokitteh
+[PiotrSikora]: https://github.com/PiotrSikora