Document the CAPZ release cadence and support policy #2628
Conversation
k8s-ci-robot
added
kind/documentation
| Any significant user-facing bug fix that lands in the `main` branch should be backported to the current and previous release lines. Security-related fixes are automatically considered significant and user-facing. | ||
|
|
||
| Improvements or significant changes to tests should be backported to the current release line. This is intended to minimize friction in the event of a critical test fix. Test improvements or changes may sometimes need to be backported to the previous release line in the event that tests break on all release branches. | ||
|
|
There was a problem hiding this comment.
Let's add a discrete section to document that for experimental APIs (e.g., AzureManagedCluster) we may include both features or bug fixes in patch releases. This an exception to the normal semver definition, but it will accelerate our effort to graduate experimental features to v1 by allowing faster feature adoption and functional iteration.
cc @CecileRobertMichon @nojnhuh @devigned @zmalik @mtougeron @LochanRn @JoelSpeed for any add'l thoughts/dissent here
There was a problem hiding this comment.
And how about another 2-3 sentences explaining that due to our minor release support contract, we want to optimize the automated cherry-pick path from main to those two minor release branches. That may include delaying codebase-wide changes like housekeeping PRs (updating downstream APIs, linting, etc) until the end of a minor release cycle. If we integrate these housekeeping PRs in the middle of a release cycle, we can then be stuck with only manual cherry-picks for the rest of the release cycle after that.
There was a problem hiding this comment.
So long as the new features are backwards compatible and don't significantly change structure or functionality I personally don't see a problem with it for experimental APIs. It really depends on what level of contract we want to provide to the users of the experimental features. I think we need to be more careful once a feature reaches beta but I definitely agree for alpha features.
There was a problem hiding this comment.
I agree with @mtougeron re: not breaking experimental APIs in a patch release. I can see where certain backwards-incompatible changes might be needed a bit sooner than the next minor release, though I think keeping experimental APIs backwards-compatible between patch releases is a good rule of thumb.
There was a problem hiding this comment.
I think this is a fair distinction:
- additive features/functionality
- changed/updated/removed features/functionality in response to the normal process of iterating in an experimental functional workstream
Part of our work in AzureManagedCluster will yield stuff that falls under #2 above. When we have a defensible reason for actually changing (i.e., breaking not just additive) an implementation classified as experimental, we should do that type of explicit breakage in a new minor release (with all-caps release notes for folks taking part in the experiment).
Does this agree with your points @nojnhuh @mtougeron?
mboersma
force-pushed
the
release-cadence
branch
from
db187df to
8639f01
Compare
|
/release-note Document the CAPZ release cadence and support policy |
|
/release-note-edit |
k8s-ci-robot
added
release-note
mboersma
force-pushed
the
release-cadence
branch
from
8639f01 to
fd1cc2a
Compare
|
/retest |
mboersma
force-pushed
the
release-cadence
branch
from
fd1cc2a to
8e373ae
Compare
k8s-ci-robot
added
the
lgtm
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: jackfrancis 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
the
approved
What type of PR is this?:
/kind documentation
What this PR does / why we need it:
Which issue(s) this PR fixes:
Fixes #2295
Special notes for your reviewer:
TODOs:
Release note: