Skip to content

Commit

Permalink
Update to time based releases
Browse files Browse the repository at this point in the history 
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 <[email protected]>
  • Loading branch information
@dmcgowan
dmcgowan committed Jan 20, 2025
1 parent 190763e commit 7a80402
Showing 1 changed file with 77 additions and 43 deletions.
120 changes: 77 additions & 43 deletions RELEASES.md
View file
Original file line number Diff line number Diff line change
Expand Up @@ -39,44 +39,42 @@ 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 time based with a target cadence of 6 months. The next two
containerd releases should have a target release date scheduled and any change
to the cadence will be considered after a new release but without 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 reach out to the maintainers 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.
Patch releases are made directly from release branches and will be done as needed
by the release branch owners.

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.
### Pre-releases

### Next Release
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.

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.
While pre-releases are done to assist in the stabilization process, no quality
guarantees are provided.

### Support Horizon

Support horizons will be defined corresponding to a release branch, identified
by `<major>.<minor>`. 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.
- __*LTS*__: The release is a long term stable branch which is currently supported and accepting patches.
Expand All @@ -101,23 +99,43 @@ own the branch but should be rejected by default. There is no limit to the numbe
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 ownership once it reaches beta. 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 two prior releases.

Once the final release is out and the release branch moves to active, ownership will be
transferred back over to all maintainers. Active releases are maintained by all maintainers
until the release reaches end of life or the branch transitions to _LTS_ with at least
two maintainers keeping ownership.

The owners of the _LTS_ branch may step down or be replaced by another maintainer at any time if
they can no longer support the branch. If no maintainers volunteer to the own a branch after
maintainers step down, the branch will end of life after 6 months of extended support with
ownership transferred back to all maintainers.


### All 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

Expand Down Expand Up @@ -223,6 +241,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
Expand Down Expand Up @@ -296,7 +329,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
Expand Down

0 comments on commit 7a80402

Please sign in to comment.