From a3cad5687f3bb69f4dbea8d11f123c27f256c5f2 Mon Sep 17 00:00:00 2001 From: Derek McGowan Date: Fri, 17 Jan 2025 17:01:03 -0800 Subject: [PATCH] Update to time based releases Adds new criteria and schedule for time based releases. Adds more ownership and roles for the different phases of the release process. Signed-off-by: Derek McGowan --- RELEASES.md | 120 ++++++++++++++++++++++++++++++++-------------------- 1 file changed, 75 insertions(+), 45 deletions(-) diff --git a/RELEASES.md b/RELEASES.md index 882f6d345833..64a3790ab95e 100644 --- a/RELEASES.md +++ b/RELEASES.md @@ -39,46 +39,41 @@ be done from that branch. For example, once we release `v1.0.0`, a branch `release/1.0` will be created from that tag. All future patch releases will be done against that branch. -### Pre-releases +### Release Cadence -Pre-releases, such as alphas, betas and release candidates will be conducted -from their source branch. For major and minor releases, these releases will be -done from main. For patch releases, these pre-releases should be done within -the corresponding release branch. +Minor releases are provided on a time basis with an initial cadence of 6 months. +The next two containerd releases should have a target release date scheduled based +on the current release cadence. Any changes to the release cadence will avoid +impacting releases which are already scheduled. -While pre-releases are done to assist in the stabilization process, no -guarantees are provided. +The maintainers will maintain a roadmap and milestones for each release, however, +features may be pushed to accomodate the release timeline. If your issue or feature +is not present in the roadmap, please open a Github issue or leave a +comment requesting it be added to a milestone. -### Upgrade Path +### Patch Releases -The upgrade path for containerd is such that the 0.0.x patch releases are -always backward compatible with its major and minor version. Minor (0.x.0) -version will always be compatible with the previous minor release. i.e. 1.2.0 -is backwards compatible with 1.1.0 and 1.1.0 is compatible with 1.0.0. There is -no compatibility guarantees for upgrades that span multiple, _minor_ releases. -For example, 1.0.0 to 1.2.0 is not supported. One should first upgrade to 1.1, -then 1.2. - -There are no compatibility guarantees with upgrades to _major_ versions. For -example, upgrading from 1.0.0 to 2.0.0 may require resources to migrated or -integrations to change. Each major version will be supported for at least 1 -year with bug fixes and security patches. +Patch releases are made directly from release branches and will be done as needed +by the release branch owners. -### Next Release +### Pre-releases -The activity for the next release will be tracked in the -[milestones](https://github.com/containerd/containerd/milestones). If your -issue or PR is not present in a milestone, please reach out to the maintainers -to create the milestone or add an issue or PR to an existing milestone. +Pre-releases, such as alphas, betas and release candidates will be conducted +from their source branch. For major and minor releases, these releases will be +done from main. For patch releases, it is uncommon to have pre-releases but +they may have an rc based on the discretion of the release branch owners. ### Support Horizon Support horizons will be defined corresponding to a release branch, identified by `.`. Release branches will be in one of several states: -- __*Next*__: The next planned release branch. +- __*Future*__: An upcoming scheduled release. +- __*Alpha*__: The next scheduled release on the main branch under active development. +- __*Beta*__: The next scheduled release on the main branch under testing. Begins 8-10 weeks before a final release. +- __*RC*__: The next scheduled release on the main branch under final testing and stabilization. Begins 2-4 weeks before a final release. For new releases where the source branch is main, the main branch will be in a feature freeze during this phase. - __*Active*__: The release is a stable branch which is currently supported and accepting patches. -- __*Extended*__: The release branch is only accepting security patches. +- __*Extended*__: The release branch is only accepting security patches and critical updates. - __*LTS*__: The release is a long term stable branch which is currently supported and accepting patches. - __*End of Life*__: The release branch is no longer supported and no new patches will be accepted. @@ -101,23 +96,42 @@ own the branch but should be rejected by default. There is no defined limit to t branches and any branch may become an _LTS_ branch after its initial release. There is no guarantee that a new _LTS_ branch will be designated before existing _LTS_ branches reach their end of life. -The current state is available in the following tables: - -| Release | Status | Start | End of Life | Owners | -| --------- | ------------- | ------------------ | -------------------------------------------------- | ---------------------- | -| [0.0](https://github.com/containerd/containerd/releases/tag/0.0.5) | End of Life | Dec 4, 2015 | - | | -| [0.1](https://github.com/containerd/containerd/releases/tag/v0.1.0) | End of Life | Mar 21, 2016 | - | | -| [0.2](https://github.com/containerd/containerd/tree/v0.2.x) | End of Life | Apr 21, 2016 | December 5, 2017 | | -| [1.0](https://github.com/containerd/containerd/releases/tag/v1.0.3) | End of Life | December 5, 2017 | December 5, 2018 | | -| [1.1](https://github.com/containerd/containerd/releases/tag/v1.1.8) | End of Life | April 23, 2018 | October 23, 2019 | | -| [1.2](https://github.com/containerd/containerd/releases/tag/v1.2.13) | End of Life | October 24, 2018 | October 15, 2020 | | -| [1.3](https://github.com/containerd/containerd/releases/tag/v1.3.10) | End of Life | September 26, 2019 | March 4, 2021 | | -| [1.4](https://github.com/containerd/containerd/releases/tag/v1.4.13) | End of Life | August 17, 2020 | March 3, 2022 | | -| [1.5](https://github.com/containerd/containerd/releases/tag/v1.5.18) | End of Life | May 3, 2021 | February 28, 2023 | | -| [1.6](https://github.com/containerd/containerd/releases/tag/v1.6.36) | LTS | February 15, 2022 | July 17, 2025 | @containerd/committers | -| [1.7](https://github.com/containerd/containerd/releases/tag/v1.7.23) | LTS | March 10, 2023 | March 10, 2026 | @containerd/committers | -| [2.0](https://github.com/containerd/containerd/releases/tag/v2.0.0) | Active | November 5, 2024 | max(November 5, 2025 or release of 2.1 + 6 months) | @containerd/committers | -| [2.1](https://github.com/containerd/containerd/milestone/48) | Next | TBD | TBD | | +### Release Owners + +Every release shall be assigned owners when entering into the beta stage of the release. The initial +release owners will act as the release captains and will be responsible for creating the releases and +ensuring the release is on time. Once the release is in rc, the release owners should be part of any +discussion around merging impactful or risky changes. Every release should have two owners who +are both active maintainers and one of which has been involved in at least two prior releases. + +Once the final release is out and the release branch moves to active, ownership will be +transferred back over to all committers. Active releases are maintained by all committers +until the release reaches end of life or the branch transitions to _LTS_. + +Every _LTS_ release requires at least two maintainers to volunteer as owners. The owners of the +_LTS_ release may step down or be replaced by another maintainer at any time if they can no longer +support the release. If no maintainers volunteer to the own the _LTS_ release after maintainers step +down, the branch will end of life after 6 months of extended support with ownership transferred back +to all committers. + +### Current State of containerd Releases + +| Release | Status | Start | End of Life | Owners | +| -------------------------------------------------------------------- | ------------- | ------------------ | ------------------ | ---------------------- | +| [0.0](https://github.com/containerd/containerd/releases/tag/0.0.5) | End of Life | Dec 4, 2015 | - | | +| [0.1](https://github.com/containerd/containerd/releases/tag/v0.1.0) | End of Life | Mar 21, 2016 | - | | +| [0.2](https://github.com/containerd/containerd/tree/v0.2.x) | End of Life | Apr 21, 2016 | December 5, 2017 | | +| [1.0](https://github.com/containerd/containerd/releases/tag/v1.0.3) | End of Life | December 5, 2017 | December 5, 2018 | | +| [1.1](https://github.com/containerd/containerd/releases/tag/v1.1.8) | End of Life | April 23, 2018 | October 23, 2019 | | +| [1.2](https://github.com/containerd/containerd/releases/tag/v1.2.13) | End of Life | October 24, 2018 | October 15, 2020 | | +| [1.3](https://github.com/containerd/containerd/releases/tag/v1.3.10) | End of Life | September 26, 2019 | March 4, 2021 | | +| [1.4](https://github.com/containerd/containerd/releases/tag/v1.4.13) | End of Life | August 17, 2020 | March 3, 2022 | | +| [1.5](https://github.com/containerd/containerd/releases/tag/v1.5.18) | End of Life | May 3, 2021 | February 28, 2023 | | +| [1.6](https://github.com/containerd/containerd/releases/tag/v1.6.36) | LTS | February 15, 2022 | July 17, 2025 | @containerd/committers | +| [1.7](https://github.com/containerd/containerd/releases/tag/v1.7.25) | LTS | March 10, 2023 | March 10, 2026 | @containerd/committers | +| [2.0](https://github.com/containerd/containerd/releases/tag/v2.0.2) | Active | November 5, 2024 | _November 7, 2025_ | @containerd/committers | +| [2.1](https://github.com/containerd/containerd/milestone/48) | Alpha | _May 7, 2025_ | _TBD_ | _TBD_ | +| [2.2](https://github.com/containerd/containerd/milestone/49) | _Future_ | _November 5, 2025_ | _TBD_ | _TBD_ | ### Kubernetes Support @@ -223,6 +237,21 @@ completed, open a PR using the process above. Only when the bug is not seen in main and must be made for the specific release branch should you open a PR with new code. +### Upgrade Path + +The upgrade path for containerd is such that the 0.0.x patch releases are +always backward compatible with its major and minor version. Minor (0.x.0) +version will always be compatible with the previous minor release. i.e. 1.2.0 +is backwards compatible with 1.1.0 and 1.1.0 is compatible with 1.0.0. There is +no compatibility guarantees for upgrades that span multiple, _minor_ releases. +For example, 1.0.0 to 1.2.0 is not supported. One should first upgrade to 1.1, +then 1.2. + +There are no compatibility guarantees with upgrades to _major_ versions. For +example, upgrading from 1.0.0 to 2.0.0 may require resources to migrated or +integrations to change. Each major version will be supported for at least 1 +year with bug fixes and security patches. + ## Public API Stability The following table provides an overview of the components covered by @@ -296,7 +325,8 @@ releases for prior API versions should be avoided if possible. | v1.6 | 1.6 | | v1.7 | 1.7 | | v2.0 | 1.8 | -| next | 1.9 | +| _v2.1_ | _1.9_ | +| _v2.2_ | _1.10_ | ### Metrics API