Add long term stable release branches

Signed-off-by: Derek McGowan <derek@mcg.dev>
This commit is contained in:
Derek McGowan 2022-09-29 14:49:32 -07:00
parent d71fbcf350
commit 8162e044b7
No known key found for this signature in database
GPG Key ID: F58C5D0A4405ACDB

View File

@ -77,11 +77,12 @@ Support horizons will be defined corresponding to a release branch, identified
by `<major>.<minor>`. Releases branches will be in one of several states:
- __*Next*__: The next planned release branch.
- __*Active*__: The release branch is currently supported and accepting patches.
- __*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.
- __*End of Life*__: The release branch is no longer supported and no new patches will be accepted.
Releases will be supported up to one year after a _minor_ release. This means that
Releases will be supported at least one year after a _minor_ release. This means that
we will accept bug reports and backports to release branches until the end of
life date. If no new _minor_ release has been made, that release will be
considered supported until 6 months after the next _minor_ is released or one year,
@ -89,6 +90,17 @@ 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. 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.
The current state is available in the following tables:
| Release | Status | Start | End of Life |
@ -102,7 +114,7 @@ The current state is available in the following tables:
| [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.11) | Active | May 3, 2021 | October 28, 2022 |
| [1.6](https://github.com/containerd/containerd/releases/tag/v1.6.4) | Active | February 15, 2022 | max(February 15, 2023 or release of 1.7.0 + 6 months) |
| [1.6](https://github.com/containerd/containerd/releases/tag/v1.6.8) | LTS | February 15, 2022 | max(February 15, 2025 or next LTS + 6 months) |
| [1.7](https://github.com/containerd/containerd/milestone/42) | Next | TBD | TBD |