containerd
/
containerd.io
mirror of https://github.com/containerd/containerd.io.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

keep releases.md in sync with containerd/containerd 

Signed-off-by: Samuel Karp <samuelkarp+automated@google.com>
This commit is contained in:
Samuel Karp 2025-02-05 18:42:08 +00:00 committed by Samuel Karp
parent 39a6b46b85
commit 557bd22c44
1 changed files with 87 additions and 63 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

150
content/releases.md
View File

@ -41,44 +41,39 @@ 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.
### Release Cadence
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.
The maintainers will maintain a roadmap and milestones for each release, however,
features may be pushed to accommodate 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.
### Patch Releases
Patch releases are made directly from release branches and will be done as needed
by the release branch owners.
### Pre-releases
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.
While pre-releases are done to assist in the stabilization process, no
guarantees are provided.
### 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.
### Next Release
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.
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.
- __*LTS*__: The release is a long term stable branch which is currently supported and accepting patches.
@ -92,43 +87,53 @@ whichever is longer. Additionally, releases may have an extended security suppor
period after the end of the active period to accept security backports. This
timeframe will be decided by maintainers before the end of the active status.
Long term stable (_LTS_) releases will be supported for at least three years after
their initial _minor_ release. These branches will accept bug reports and
backports until the end of life date. They may also accept a wider range of
patches than non-_LTS_ releases to support the longer term maintainability of the
branch, including library dependency, toolchain (including Go) and other version updates
which are needed to ensure each release is built with fully supported dependencies and
remains usable by containerd clients. _LTS_ releases can also accept feature backports
to support new Kubernetes releases. The default action has to be reject it though,
for long-term stability. This is still negotiable when the feature is a hard dependency
for a new release of Kubernetes. There should be at least a 6-month overlap between
the end of life of an _LTS_ release and the initial release of a new _LTS_ release.
Up to 6 months before the announced end of life of an _LTS_ branch, the branch may
convert to a regular _Active_ release with stricter backport criteria.
Long term stable (_LTS_) releases are owned by at least two maintainers for at least two
years after their initial _minor_ (x.y.0) release. The maintainers of the _LTS_ branch may commit to
a longer period or extend the support period as needed. These branches will accept bug reports and
backports until the end of life date. They may also accept a wider range of patches than non-_LTS_
releases to support the longer term maintainability of the branch, including library dependency,
toolchain (including Go) and other version updates which are needed to ensure each release is built
with fully supported dependencies. Feature backports are up to the discretion of the maintainers who
own the branch but should be rejected by default. There is no defined limit to the number of _LTS_
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 Owners
| Release | Status | Start | End of Life |
| --------- | ------------- | ------------------ | ------------------- |
| [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 | next LTS + 6 months |
| [1.7](https://github.com/containerd/containerd/releases/tag/v1.7.23) | Active | March 10, 2023 | active(May 5, 2025), extended(EOL of 1.6) |
| [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) |
| [2.1](https://github.com/containerd/containerd/milestone/48) | Next | TBD | TBD |
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.
> **_NOTE_** containerd v1.7 will end of life at the same time as v1.6 LTS. Due to
> [Minimal Version Selection](https://go.dev/ref/mod#minimal-version-selection) used
> by Go modules, 1.7 must be supported until EOL of all 1.x releases. Once 1.7 is in
> extended support, it will continue to accept security patches in addition to client
> changes relevant for package importers using the 1.6 LTS daemon.
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 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.0) | LTS | February 15, 2022 | July 23, 2025 | @containerd/committers |
| [1.7](https://github.com/containerd/containerd/releases/tag/v1.7.0) | 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 | November 7, 2025 (_tentative_) | @containerd/committers |
| [2.1](https://github.com/containerd/containerd/milestone/48) | Alpha | May 7, 2025 (_tentative_) | _TBD_ | _TBD_ |
| [2.2](https://github.com/containerd/containerd/milestone/49) | _Future_ | November 5, 2025 (_tentative_) | _TBD_ | _TBD_ |
### Kubernetes Support
@ -234,6 +239,24 @@ 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 2.0, migration was
added to ensure upgrading from 1.6 or 1.7 to 2.0 is easy. The latest releases of 1.6 and 1.7 provide
deprecation warnings if any configuration is used which is incompatible with 2.0. If deprecation
warnings are showing up, the configuration can be safely migrated in 1.6 or 1.7 before upgrading to
2.0. Once no deprecation warnings are showing up, the upgrade to 2.0 should be smooth. Always
check the release notes, breaking changes are listed there, and test your configuration before
upgrading.
## Public API Stability
The following table provides an overview of the components covered by
@ -307,7 +330,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