ContextQMD
Back to Envoy

Release Process

RELEASES.md

1.38.011.4 KB
Original Source

Release Process

Active development

Active development is happening on the main branch, and a new version is released from it.

Stable releases

Stable releases of Envoy include:

  • Major releases in which a new version a created directly from the main branch.
  • Minor releases for versions covered by the 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).
    • Stability fixes backported from the main 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.

Major releases happen quartely and follow the schedule below. Security fixes typically happen quarterly as well, but this depends on the number and severity of security bugs. Other releases are ad-hoc and best-effort.

Security releases

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.

Backports

All other security and reliability fixes can be nominated for backporting to stable releases by adding the backport/review label (this can be done using [repokitteh]'s /backport command on PRs).

Only security and reliability fixes are backported, so please consider this before proposing a backport.

Envoy release maintainers will try to review and include any pending proposed backports prior to patch releases. Backports can also be proposed directly, by raising a PR against the relevant release branch, eg release/v1.37.

When raising a backport, please raise against all supported branches, that are affected.

Backport PRs should pick specific commits from the main branch, and should be kept as specific commits while tracking the upstream release branch, before landing.

For this reason, change should be managed using rebase rather than merge, and if adjustments are required they should be squashed into the relevant commit.

Release branches are published as part of the security schedule described below, and immediately prior to a main release.

Release management

Major releases are handled by the maintainer on-call and do not involve any backports. The details are outlined in the "Cutting a major release" section below. Security releases are handled by a Release Manager and a Fix Lead. The Release Manager is responsible for approving and merging backports, with responsibilties outlined in BACKPORTS.md. 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.

QuarterRelease ManagerFix Lead
2020 Q1Piotr Sikora (PiotrSikora)
2020 Q2Piotr Sikora (PiotrSikora)
2020 Q3Yuchen Dai (lambdai)
2020 Q4Christoph Pakulski (cpakulski)
2021 Q1Rei Shimizu (Shikugawa)
2021 Q2Dmitri Dolguikh (dmitri-d)
2021 Q3Takeshi Yoneda (mathetake)
2021 Q4Otto van der Schaaf (oschaaf)
2022 Q1Otto van der Schaaf (oschaaf)Ryan Hamilton (RyanTheOptimist)
2022 Q2Pradeep Rao (pradeepcrao)Matt Klein (mattklein123)
2022 Q4Can Cecen (cancecen)Tony Allen (tonya11en)
2023 Q3Boteng Yao (botengyao)Kateryna Nezdolii (nezdolik)
2023 Q4Paul Merrison (pmerrison)Brian Sonnenberg (briansonnenberg)
2024 Q2Ryan Northey (phlax)Boteng Yao (botengyao)
2024 Q3Ryan Northey (phlax)Boteng Yao (botengyao)
2025 Q1Ryan Northey (phlax)Boteng Yao (botengyao)
2025 Q3Ryan Northey (phlax)Yan Avlasov (yanavlasov)
2025 Q4Ryan Northey (phlax)Boteng Yao (botengyao)
2026 Q1Ryan Northey (phlax)Boteng Yao (botengyao)
2026 Q2Ryan Northey (phlax)Boteng Yao (botengyao)

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 deadline of 3 weeks.

VersionExpectedActualDifferenceEnd of Life
1.12.02019/09/302019/10/31+31 days2020/10/31
1.13.02019/12/312020/01/20+20 days2021/01/20
1.14.02020/03/312020/04/08+8 days2021/04/08
1.15.02020/06/302020/07/07+7 days2021/07/07
1.16.02020/09/302020/10/08+8 days2021/10/08
1.17.02020/12/312021/01/11+11 days2022/01/11
1.18.02021/03/312021/04/15+15 days2022/04/15
1.19.02021/06/302021/07/13+13 days2022/07/13
1.20.02021/09/302021/10/05+5 days2022/10/05
1.21.02022/01/152022/01/12-3 days2023/01/12
1.22.02022/04/152022/04/150 days2023/04/15
1.23.02022/07/152022/07/150 days2023/07/15
1.24.02022/10/152022/10/19+4 days2023/10/19
1.25.02023/01/152023/01/18+3 days2024/01/18
1.26.02023/04/152023/04/18+3 days2024/04/18
1.27.02023/07/142023/07/27+13 days2024/07/27
1.28.02023/10/162023/10/19+3 days2024/10/19
1.29.02024/01/162024/01/160 days2025/01/16
1.30.02024/04/162024/04/160 days2025/04/16
1.31.02024/07/162024/07/19+3 days2025/07/19
1.32.02024/10/152024/10/150 days2025/10/15
1.33.02025/01/142025/01/140 days2026/01/14
1.34.02025/04/152025/04/150 days2026/04/15
1.35.02025/07/152025/07/238 days2026/07/23
1.36.02025/10/142025/10/140 days2026/10/14
1.37.02026/01/132026/01/130 days2027/01/13
1.38.02026/04/14

Cutting a major release

  • Take a look at open issues tagged with the current release, by searching 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 aim for main to be at release candidate quality at all times.
  • Do a final check of the release notes:
    • Make any needed corrections (grammar, punctuation, formatting, etc.).
    • Check to see if any security/stable version release notes are duplicated in the major version release notes. These should not be duplicated.
    • Switch the repo to "release" mode by running bazel run @envoy_repo//:release. This tool will create a commit with the necessary changes for a release.
    • Update the RELEASES doc with the relevant dates. Now, or after you cut the release, please also make sure there's a stable maintainer signed up for next quarter, and the deadline for the next release is documented in the release schedule.
    • Get a review and merge.
  • Create a pull request with that commit and wait for tests to pass.
  • Once the tests have passed, and the PR has landed, CI will automatically create the tagged release and corresponding release branch.
  • Switch the repo back to "dev" mode by running bazel run @envoy_repo//:dev. This tool will create a commit with the necessary changes to continue development.
  • Create a pull request with that commit.
  • Run the deprecate_guards.py script (bazel run //tools/deprecate_guards:deprecate_guards)
  • If you haven't done this before, request posting permission from admins for all the groups in the next bullet.
  • Craft a witty/uplifting email and send it to all the email aliases: [email protected] [email protected] [email protected] [email protected] - include in this email a link to the latest release page (ending in tag/[version])
  • Announce in #envoy-dev and #envoy-users slack channels.

Security release schedule

Security releases are published on a 3-monthly cycle, around the mid point between major releases.

QuarterExpectedActualDifference
2024 Q22024/06/042024/06/040 days
2024 Q32024/09/032024/09/1916 days
2024 Q42024/12/032024/12/1815 days
2025 Q12025/03/042025/03/2016 days
2025 Q22025/06/03----
2025 Q32025/09/022025/09/031 day
2025 Q42025/12/022025/12/031 day
2026 Q12026/03/032026/01/107 days
2026 Q22026/06/02

NOTE: Zero-day vulnerabilities, and upstream vulnerabilities disclosed to us under embargo, may necessitate an emergency release with little or no warning.