[VEP #233] Enforce Release Branch End-of-Life Policy

[Lee Yarwood]

I've opened a VEP proposing that KubeVirt adopt an enforced
End-of-Life policy for release branches, limiting active maintenance
to the 3 most recent minor releases.

VEP: https://github.com/kubevirt/enhancements/pull/234
Tracking issue: https://github.com/kubevirt/enhancements/issues/233

The problem

KubeVirt currently has 59 release branches with no enforced EOL. While
docs/release.md states that EOL is tied to the Kubernetes support
period, but it explicitly notes that this is "currently" not enforced.
In practice, this means CVE fixes and dependency updates are
backported to an ever-growing number of branches well beyond any
reasonable support window.

The proposal

Adopt the same model Kubernetes uses: support the 3 most recent minor
releases, with a hard cutoff. With our 3-releases-per-year cadence,
this gives users approximately 12-15 months to upgrade — a generous
window that aligns with typical upgrade cycles.

Benefits

- Reduced CI cost: Maintaining CI lanes for old release branches
consumes infrastructure resources and debugging time when ancient
branches break due to infrastructure drift. Bounding to 3 branches
makes this predictable and sustainable.
- Lower maintenance burden: The HTTP/2 rapid reset CVE alone required
7 separate cherry-pick PRs, each needing review and CI validation.
Under this policy, that would have been 3. Every future CVE benefits
from this reduction.
- Clear expectations for users: Today, users on old releases receive
sporadic fixes with no guarantee of comprehensive coverage. A hard EOL
gives them a clear signal to upgrade and removes the false sense of
security.
- Consistency with our own documentation: The release docs already tie
EOL to the Kubernetes support period. This VEP simply enforces what
we've already stated.
- Alignment with the ecosystem: Kubernetes, etcd, and most CNCF
projects enforce hard EOL windows. Adopting the same model makes
KubeVirt's lifecycle predictable for downstream consumers.

The VEP includes a transition plan with a one-release-cycle grace
period, so no one is caught off guard. Downstream distributors who
need longer support windows can continue to maintain their own
backports independently — this policy only affects upstream.

I'd appreciate reviews and feedback from the community, particularly
from SIG Release and anyone involved in release branch maintenance.

Cheers,

Lee