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 22, 2025
1 parent 886d971 commit d0a53f4
Showing 1 changed file with 75 additions and 45 deletions.
120 changes: 75 additions & 45 deletions RELEASES.md
View file
Original file line number Diff line number Diff line change
Expand Up @@ -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. Changes to the release cadence will not impact
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 `<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.
- __*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.

Expand All @@ -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 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 at least two owners who are all active
maintainers and one of which has been a release owner 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 23, 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 +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
Expand Down Expand Up @@ -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
Expand Down

0 comments on commit d0a53f4

Please sign in to comment.