Allow the certification of old versions of Kubernetes when the provider has a current registration #414
Conversation
…er has a current registration
| @@ -64,7 +64,7 @@ _Conformance Time Period; Later Versions of Kubernetes_. A Participant’s permi | |||
| * 12 months after the release date of Kubernetes x.y, or | |||
| * 9 months after the release date of the next minor release (e.g., Kubernetes x.y+1). | |||
|
|
|||
| However, notwithstanding the time limits above, the Participant may also continue to use the Certified Kubernetes Marks and Participant Kubernetes Combinations for any prior version of Kubernetes for which the offering was a Qualifying Offering, for so long as (1) the offering continues to be a Qualifying Offering for each subsequent version of Kubernetes; (2) the Qualifying Offering with the subsequent version of Kubernetes is made generally available to users of the prior version; and (3) the Participant otherwise continues to abide by the terms of the Conformance Program. | |||
| However, notwithstanding the time limits above, the Participant may also continue to certify and use the Certified Kubernetes Marks and Participant Kubernetes Combinations for any prior version of Kubernetes for which the offering was a Qualifying Offering, for so long as (1) the offering continues to be a Qualifying Offering for each subsequent version of Kubernetes; (2) the Qualifying Offering with the subsequent version of Kubernetes is made generally available to users of the prior version; and (3) the Participant otherwise continues to abide by the terms of the Conformance Program. | |||
There was a problem hiding this comment.
Just FYI - this diff not showing what changed is why some groups try to stick with 80 columns :-)
Is the only diff the new words "certify and" in the first line?
|
@WilliamDenniss Could you please add a little more context about why this PR is necessary if #413 is approved? Today, a provider can certify K8s versions 1.13 and 1.12. If #413 is approved, they would also have the option of certifying 1.11. If this PR is approved, a provider who first certifies 1.12 or 1.13 would then have the option of certifying versions 1.0 through 1.10. However, security releases are only available for the last 3 versions, so 1.11 and higher. (See https://github.com/kubernetes/community/blob/master/contributors/design-proposals/release/versioning.md ) I'm an explicit -1 on the idea of allowing new certification of a K8s version that is not getting security releases. I understand that some vendors are backporting fixes to older releases, but I'm unconvinced that we want to use the signaling mechanism of certification to support new vendors doing security releases for older versions. So, unless I'm misunderstanding some of the versioning here, I think support of #413 largely eliminates the need for this PR. Cc @swinslow |
|
Per the discussion on the call today I'm closing this for now, if anyone has a need for this please make your case. Here's the rationale for the record: Currently a provider who certified 1.10 can remain certified and continue to offer Certified Kubernetes 1.10 (provided they also have a more current version on offer), however a new participant can not do this. The idea behind this PR was to equalize this so that that all participants can offer the same versions, regardless of when they join or certify (provided they continue to offer a current release, per the terms). |
Per email thread, updated terms for review.