Adding Release Cycle Documentation #3063
Conversation
k8s-ci-robot
added
do-not-merge/hold
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: robscott The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
k8s-ci-robot
added
size/L
| | Major GEP Updates | ✅ | ✅ | ❌ | ❌ | | ||
| | GEP Refinement | ✅ | ✅ | ✅ | ❌ | | ||
| | API Spec Additions | ❌ | ❌ | ✅ | ❌ | | ||
| | New Conformance Tests | ✅ | ✅ | ✅ | ❌ | |
There was a problem hiding this comment.
Other than being noted here, I don't see a phase that details conformance tests. Are conformance tests optional when adding or updating a GEP?
There was a problem hiding this comment.
Good question - presently the only requirement for conformance tests is that a minimum of 3 implementations must be passing conformance tests for a GEP to graduate to standard channel. We don't actually require conformance tests when adding new experimental features, but they are encouraged. It can be challenging to write conformance tests without any implementations though.
|
|
||
| ## Goals | ||
|
|
||
| * Ensure a predictable release schedule that enables 2-3 releases a year |
There was a problem hiding this comment.
imo 2-3 itself is vague
can we add more clarity here ? e.g.
There was a problem hiding this comment.
That's definitely my longer term goal, but I think we need to try at least one of these structured releases before we can confidently predict dates with that level of precision. The current goal is to set dates for a minimum of 1 phase in advance, but ideally more. Hopefully once we have some experience, we'll be able to set dates for every phase in a release cycle upfront, matching upstream Kubernetes. The biggest thing that could help us would be having people that can help push things forward, especially with this release process.
|
Thanks to everyone for the feedback! Since v1.2 release cycle is already beginning, we're going to go with lazy consensus here and plan on merging in another 24 hours. Please get any additional feedback in before then. |
|
/unhold |
k8s-ci-robot
removed
the
do-not-merge/hold
k8s-ci-robot
added
the
lgtm
What type of PR is this?
/kind documentation
What this PR does / why we need it:
This is a follow up from a doc I shared at the community meeting earlier this week. This builds on that by formally adding it to our documentation.
Does this PR introduce a user-facing change?:
/hold for consensus