支持的版本¶

支持的版本，Kubernetes 版本，OpenShift 版本和即将发布的时间表

受到 https://istio.io/latest/about/supported-releases/ 启发

本页列出当前支持版本的状态、时间轴和策略。

每个版本支持四个月的时间，我们的目标是大约每两个月创建一个新版本，包括假日期间、主要会议和其他世界事件。

cert-manager 希望所有 Kubernetes(1.24 及以上版本)的集群中都启用 ServerSideApply。

当前支持的版本

应该在集群中启用 ServerSideApply

即将发布的¶

未来的日期是不确定的，可能会改变。

旧的版本¶

We list cert-manager releases on GitHub, and release notes on cert-manager.io.

We also maintain detailed upgrade instructions.

支持政策¶

支持是什么意思¶

Our support window is four months for each release branch. In the below diagram, release-1.2 is an example of a release branch. The support window corresponds to the two latest releases, given that we produce a new final release every two months. We offer two types of support:

• Technical support,
• Security and bug fixes.

For example, imagining that the latest release is v1.2.0, you can expect support for both v1.2.0 and v1.1.0. Only the last patch release of each branch is actually supported.

   v1.0.0                                                          ^
 Sep 2, 2020                                                       | UNSUPPORTED
------+---------------------------------------------> release-1.0  | RELEASES
       \                                                           v
        \
         \       v1.1.0
          \    Nov 24, 2020                                        ^
           ---------+-------------------------------> release-1.1  |
                     \                                             | SUPPORTED
                      \                                            | RELEASES
                       \         v1.2.0                            | = the two
                        \      Feb 10, 2021                        |   last
                         ------------+--------------> release-1.2  |   releases
                                      \                            v
                                       \
                                        \
                                         \
                                          -----------> master branch
                                                       April 1, 2021

技术支持

Technical assistance is offered on a best-effort basis for supported releases only. You can request support from the community on Kubernetes Slack (in the #cert-manager channel), using GitHub Discussions or using the cert-manager-dev Google group.

Security and bug fixes

We back-port important bug fixes — including security fixes — to all currently supported releases.

• Security issues,
• Critical bugs,
• Long-standing bugs.

Security issues

Security issues are fixed as soon as possible. They get back-ported to the last two releases, and a new patch release is immediately created for them.

Critical bugs

Critical bugs include both regression bugs as well as upgrade bugs.

Regressions are functionalities that worked in a previous release but no longer work. #4142, #3393 and #2857 are three examples of regressions.

Upgrade bugs are issues (often Helm-related) preventing users from upgrading to currently supported releases from earlier releases of cert-manager. #3882 and #3644 are examples of upgrade bugs.

Note that intentional breaking changes do not belong to this category.

Fixes for critical bugs are (usually) immediately back-ported by creating a new patch release for the currently supported releases.

Long-standing bugs

Long-standing bug: sometimes a bug exists for a long time, and may have known workarounds. #3444 is an example of a long-standing bug.

Where we feel that back-porting would be difficult or might be a stability risk to clusters running cert-manager, we'll make the fix in a major release but avoid back-porting the fix.

Breaking changes

Breaking changes are changes that intentionally break the cert-manager Kubernetes API or the command line flags. We avoid making breaking changes where possible, and where they're required we'll give as much notice as possible.

Other back-ports

We aim to be conservative in what we back-port. That applies especially for anything which could be a runtime change - that is, a change which might alter behavior for someone upgrading between patch releases.

That means that if a candidate for back-porting has a chance of having a runtime impact we're unlikely to accept the change unless it addresses a security issue or a critical bug.

We reserve the right to back-port other changes which are unlikely to have a runtime impact, such as documentation or tooling changes. An example would be #5209 which updated how we perform a release of cert-manager but didn't have any realistic chance of having a runtime impact.

Generally we'll seek to be pragmatic. A rule of thumb might be to ask:

"Does this back-port improve cert-manager, bearing in mind that we really value stability for already-released versions?"

How we determine supported Kubernetes versions

The list of supported Kubernetes versions displayed in the Supported Releases section depends on what the cert-manager maintainers think is reasonable to support and to test.

In practice, this is largely determined based on what versions of kind are available for testing, and which versions of Kubernetes are provided by major upstream cloud Kubernetes vendors including EKS, GKE, AKS and OpenShift.

*Oldest release relevant to the next cert-manager release, as of 2022-07-18

OpenShift¶

cert-manager 支持基于 Kubernetes 版本的 OpenShift 4 版本。

For convenience, the following table shows these version mappings:

Note that some OpenShift versions listed above may be predicted, since an updated version of OpenShift may not yet be available for the latest Kubernetes releases.

The last version of cert-manager to support OpenShift 3 was cert-manager 1.2, which is no longer maintained.

术语¶

The term "release" (or "minor release") refers to one minor version of cert-manager. For example, 1.2 and 1.3 are two releases. Note that we do not use the prefix v for releases (just "1.2"). This is because releases are not used as git tags.

Patch releases use the v prefix (e.g., v1.2.0, v1.3.1...) since one patch release = one git tag. The initial patch release is called "final release":

*For maintainers: each release has an associated long-lived branch that we call the “release branch”. For example, release-1.2 is the release branch for release 1.2.

**Pre-releases (e.g., v1.3.0-alpha.0) don't have a corresponding release (e.g., 1.3) since a release only exists after a final release (e.g., v1.3.0) has been created.

Our naming scheme mostly follows Semantic Versioning 2.0.0 with v prepended to git tags and docker images:

v<major>.<minor>.<patch>

where <minor> is increased for each release, and <patch> counts the number of patches for the current <minor> release. A patch is usually a small change relative to the <minor> release.