Update versioning docs to reflect recent changes in the release process. #4308
Conversation
k8s-ci-robot
added
release-note
|
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: bexxmodd The full list of commands accepted by this bot can be found here.
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
k8s-ci-robot
added
the
size/M
|
/cc @kflynn |
k8s-ci-robot
added
the
cncf-cla: yes
site-src/concepts/versioning.md
Outdated
| To get a new item into the Experimental channel, you need: | ||
| * A Who/What/Why [GEP](../geps/overview.md) merged as Provisional | ||
| * Implementations willing to sponsor the item by agreeing to implement it as an | ||
| experimental feature | ||
| * Items affecting north-south aspects of Gateway API require three sponsors | ||
| * Items affecting only east-west aspects require two sponsors | ||
|
|
||
| The GEP can be merged into Provisional before soliciting sponsors. Once an item | ||
| moves from Provisional to Implementable, it will be automatically dropped if it | ||
| doesn't make any significant progress in six months. This process is handled | ||
| with a public review, typically at the first meeting of every month. |
There was a problem hiding this comment.
I'm worried that this will go stale - any chance we could put something like "There are requirements for each level change, and those are documented at ". That way, if we update the GEP overview doc with the process, we don't need to update it here as well.
There was a problem hiding this comment.
Updated this section to point to the original discussion where new requirements are present.
There was a problem hiding this comment.
I think the right answer here is a link to https://gateway-api.sigs.k8s.io/geps/overview/ and, of course, making sure that that document reflects reality.
There was a problem hiding this comment.
Given that is already linked at the start of the diagram, I'll completely remove this paragraph.
| A>Experimental Channel] --> B([Widely used and working well?]) | ||
| B -->|Yes| C>Standard Channel] | ||
| B -->|No| D([Could Changes Help?]) | ||
| D -->|Yes| E([Adjust and try again]) | ||
| D -->|No| F>Remove From API] | ||
| E -->A | ||
|
|
||
| 2 -->|No progress in 6 months| G([Auto-dropped]) |
There was a problem hiding this comment.
I think this should go from experimental channel instead of provisional. IMO it's fine for ideas to sit in "provisional" indefinitely, but as soon as they become part of the API surface, they need to either move forward or get dropped so we're not stuck with an alpha API that's treated as stable simply because it's existed a long time.
| ## Release Process | ||
|
|
||
| ### Standard Channel Releases | ||
| Standard-channel releases follow a date-based cadence. The release date is |
There was a problem hiding this comment.
@kflynn @youngnick @rikatz Are we OK about being more prescriptive here, such as "we target a 4 month cadence for standard channel releases"?
| The purpose of monthly releases is to enable faster iteration in the | ||
| Experimental channel. | ||
|
|
||
| ### SemVer Releases |
There was a problem hiding this comment.
I think we need to be careful here. We use "semantic versioning terminology", but we also include breaking changes in minor releases (thanks to experimental channel), and therefore aren't strictly following semantic versioning. Kubernetes upstream is pretty careful how it words this: https://kubernetes.io/releases/version-skew-policy/#supported-versions. I think we should go further and say that semantic versioning concepts only apply to how we structure versions, but that we have a broader set of acceptable changes in any given release (https://gateway-api.sigs.k8s.io/concepts/versioning/#what-can-change).
| will wait for the next release. The release number is ideally chosen at the | ||
| point when its content is known. | ||
|
|
||
| ### Monthly Experimental Releases |
5 participants
/kind documentation
What this PR does / why we need it:
Update versioning docs to reflect recent changes in the release process.
Which issue(s) this PR fixes:
Fixes #4282
Does this PR introduce a user-facing change?: