docs: Attempt to flesh out the different release responsibilities #20851
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -8,6 +8,11 @@ Active development is happening on the `main` branch, and a new version is relea | |
|
|
||
| Stable releases of Envoy include: | ||
|
|
||
| TODO(RyanTheOptimist): It seems to me that we have two kinds of releases and it would be helpful for | ||
| this doc to make a clear distinction between them. For the sake of argument, I've called them | ||
| "Major Release" (v1.22) and "Security Releases" (v1.22.1, etc). Does this terminology work? | ||
|
|
||
| * Major releases in which a new version a created directly from the `main` branch. | ||
| * Extended maintenance window (any version released in the last 12 months). | ||
| * Security fixes backported from the `main` branch (including those deemed not worthy | ||
| of creating a CVE). | ||
|
|
@@ -22,11 +27,12 @@ version from the `main` branch by creating a `vX.Y.0` tag and a corresponding `r | |
| branch, with merge permissions given to the release manager of stable releases, and CI configured | ||
| to execute tests on it. | ||
|
|
||
| ### Security Releases | ||
RyanTheOptimist marked this conversation as resolved.
Show resolved
Hide resolved
|
||
|
|
||
| Critical security fixes are owned by the Envoy security team, which provides fixes for the | ||
| `main` branch. Once those fixes are ready, the maintainers | ||
| of stable releases backport them to the remaining supported stable releases. | ||
| TODO(RyanTheOptimist): Should this perhaps mention that this process is not "in-the-clear"? | ||
|
|
||
| ### Backports | ||
|
|
||
|
|
@@ -40,25 +46,30 @@ are backported from the `main` branch to all supported stable branches by the ma | |
| 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 | ||
|
|
||
| Major releases are handled by Matt Klein ([mattklein123](https://github.com/mattklein123)) | ||
| or Alyssa Wilk ([alyssawilk](https://github.com/alyssawilk)) and do not involve any backports. | ||
|
There was a problem hiding this comment. It would be nice if other people did this. :) There was a problem hiding this comment. Completely agree :) Should we set up a rotation? I'd be happy to add a column to the schedule below. Are there any steps in the stable release process with require a repo admin? (I seem to recall needing repo admin help from repo admins in the security release process). There was a problem hiding this comment. Sure a rotation would be great. I think it might require an admin to actually make the release (I'm not sure) but that is a tiny step. There was a problem hiding this comment. I talked to @alyssawilk about this and she proposed making this the responsibility of the on-call maintainer, which makes a lot of sense to me. It's not much work in the grand scheme of things so it should fit nicely on that person's plate. |
||
| Security releases are handled by a Release Manager and a Fix Lead. The Release Manager is | ||
| responsible for approving and merging backports. The Fix Lead is a member of the security | ||
| team and is responsible for coordinating the overall release. This includes identifying | ||
| issues to be fixed in the release, communications with the Envoy community, and the | ||
| actual mechanics of the release itself. | ||
|
There was a problem hiding this comment. do we want to link to the docs here? is there anything private in the doc? AFIK the release manager generally responsible for doing backports for releases. Also somewhere maybe we should outline all the responsibilities for the role? Right now they're docced up here https://docs.google.com/document/d/1AnIqmJlGlN0nZaxDme2uMjcO9VJxIokGDMYsq2IZM98/edit but we could fold the content in here and delete that doc? There was a problem hiding this comment. Oh, I didn't realize that doc existed. I added a link to it. But I'd be happy to inline it here, if you think that would be better? There was a problem hiding this comment. yeah I think inlining would be better but you're already voluntering for enough improvements so your call :-) There was a problem hiding this comment. Will do! But I'll do it in a follow up so as not to drag this PR out any longer.
alyssawilk marked this conversation as resolved.
Show resolved
Hide resolved
|
||
|
|
||
| | Quarter | Release Manager | Fix Lead | | ||
| |:-------:|:--------------------------------------------------------------:|:----------------------------------------------------------------------| | ||
| | 2020 Q1 | Piotr Sikora ([PiotrSikora](https://github.com/PiotrSikora)) | | | ||
| | 2020 Q2 | Piotr Sikora ([PiotrSikora](https://github.com/PiotrSikora)) | | | ||
| | 2020 Q3 | Yuchen Dai ([lambdai](https://github.com/lambdai)) | | | ||
| | 2020 Q4 | Christoph Pakulski ([cpakulski](https://github.com/cpakulski)) | | | ||
| | 2021 Q1 | Rei Shimizu ([Shikugawa](https://github.com/Shikugawa)) | | | ||
| | 2021 Q2 | Dmitri Dolguikh ([dmitri-d](https://github.com/dmitri-d)) | | | ||
| | 2021 Q3 | Takeshi Yoneda ([mathetake](https://github.com/mathetake)) | | | ||
| | 2021 Q4 | Otto van der Schaaf ([oschaaf](https://github.com/oschaaf)) | | | ||
| | 2022 Q1 | Otto van der Schaaf ([oschaaf](https://github.com/oschaaf)) | Ryan Hamilton ([RyanTheOptimist](https://github.com/RyanTheOptimist)) | | ||
| | 2022 Q2 | Pradeep Rao ([pradeepcrao](https://github.com/pradeepcrao)) | TBD | | ||
|
|
||
| ## Major Release Schedule | ||
|
|
||
| In order to accommodate downstream projects, new Envoy releases are produced on a fixed release | ||
| schedule (the 15th day of each quarter), with an acceptable delay of up to 2 weeks, with a hard | ||
|
|
@@ -79,4 +90,5 @@ deadline of 3 weeks. | |
| | 1.22.0 | 2022/04/15 | 2022/04/15 | 0 days | 2023/04/15 | | ||
| | 1.23.0 | 2022/07/15 | | | | | ||
|
|
||
| TODO(RyanTheOptimist): Should we also mention the security release schedule here? I think that would be helpful. | ||
RyanTheOptimist marked this conversation as resolved.
Show resolved
Hide resolved
|
||
| [repokitteh]: https://github.com/repokitteh | ||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think we effectively have 3 (well 2 with 1 having 2 subtypes):
The release mechanics for 2 and 3 are very similar, there is just more private coordination required for 2.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oh, interesting. I wasn't aware that we did minor releases for non-security reasons. Are these ad-hoc releases, or are they scheduled in some way? Presumably we should talk about these releases in this doc somewhere?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
They are basically ad-hoc and best effort. It's essentially if someone wants to do the work. I agree we should discuss this option and make it clear that it's best effort and requires people to volunteer for release work.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ok, I've updated this section to hopefully make this point clear. WDYT?