/sig api-machinery

cc @Jefftree @aaron-prindle

cc @thockin

Other than the emulation version guidance bits, a couple policies also need to be revised imo.

1. https://github.com/kubernetes/community/blob/master/contributors/devel/sig-architecture/feature-gates.md#ga-features:

After at least two releases post-GA and deprecation, feature gates should be removed.

We will need to enforce 3 releases to support proper n-3

2. https://kubernetes.io/docs/reference/using-api/deprecation-policy/#deprecation:

Rule #9: Feature gates must be deprecated when the corresponding feature they control transitions a lifecycle stage as follows. Feature gates must function for no less than:
Beta feature to GA: 6 months or 2 releases (whichever is longer)
Beta feature to EOL: 3 months or 1 release (whichever is longer)
Alpha feature to EOL: 0 releases

Beta features are able to be deprecated in one release and alpha features can be deprecated immediately. For the most accurate emulation, it seems like we would want n-3 with these as well? I'm a bit unsure about the alpha case because they would be disabled by default and are expected to be unstable so we might not even support full emulation for complicated alphas.

I think n-3 applies for beta, but ISTR that alpha was explicitly not covered? Or did I dream that?

proper n-3

please explain on the docs update where the n-3 rationale is coming

alpha was explicitly not covered

is there any reason or benefit in covering alphas? we better not cover all alphas, no?

I think n-3 applies for beta, but ISTR that alpha was explicitly not covered? Or did I dream that?

I probably mentioned this. I has proposed this in the original KEP: "Non-Goals; Support --emulation-version for Alpha features. Alpha feature are not designed to be upgradable, so we will not allow alpha features to be enabled when --emulation-version is set." https://github.com/kubernetes/enhancements/blob/master/keps/sig-architecture/4330-compatibility-versions/README.md#non-goals.

I really like the simplification of not having to deal with alpha APIs/features at all with compatibility version. But I don't know if we ever implemented a check that prevents enabling alpha APIs/features when --emulate-version is set. So there are details we need to follow up on.

proper n-3

please explain on the docs update where the n-3 rationale is coming

+1 to adding to docs. What I remember us deciding was to make it possible to do a skip-level upgrade from the oldest supported k8s version to the newest supported k8s version. So supporting --emulate-version up to n-3 (or is it n-4?) such that this is possible seemed particularly valuable.

alpha was explicitly not covered

is there any reason or benefit in covering alphas? we better not cover all alphas, no?

I don't see any value to supporting alpha enablement in conjunction with --emulate-version. xref: #8082 (comment)

--emulate-version up to n-3 (or is it n-4?)

n-3 https://github.com/kubernetes/enhancements/tree/master/keps/sig-architecture/3935-oldest-node-newest-control-plane#summary

I don't see any value to supporting alpha enablement

agree, and omitting this does not stop anybody in the future to work on enable it

One thing this changes, unless I misunderstand:

• Previously we could remove all the gate-related logic when a gate became GA. Then, +2 releases, we would remove the gate itself.
• Now we have to leave the gated logic, even when GA. At +3 releases we can remove the gated logic AND the gate itself.

Right?

One thing this changes, unless I misunderstand:

• Previously we could remove all the gate-related logic when a gate became GA. Then, +2 releases, we would remove the gate itself.
• Now we have to leave the gated logic, even when GA. At +3 releases we can remove the gated logic AND the gate itself.

Right?

Correct, working on updating the docs here #8087