[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

[Lee Yarwood]

Hi all,

I wanted to bump this thread and ask for any feedback or concerns from
the community on VEP #233.

The PR (https://github.com/kubevirt/enhancements/pull/234) has been
open for almost a month now without any reviews, and I'd really
appreciate input from SIG Release and the wider community to help move
this forward.

To briefly recap, this VEP proposes adopting a hard EOL policy for
KubeVirt release branches, limiting active maintenance to the 3 most
recent minor releases. The project currently has 61 release branches
with no enforced EOL, and this number continues to grow with every
release.

I believe this enhancement would still be very beneficial for the
upstream project:

- **Reducing unsustainable maintenance burden** — CVE backports
currently fan out across far too many branches. For example,
CVE-2023-39325 required backports to 7 branches when only 3 would have
been in scope under this policy.
- **Cutting unbounded CI costs** — maintaining CI for branches
targeting long-EOL Kubernetes versions wastes infrastructure and
maintainer time when those jobs inevitably break due to infrastructure
drift.
- **Eliminating false security for users** — sporadic fixes on ancient
branches give users a false sense of maintenance without comprehensive
coverage.
- **Aligning with the Kubernetes model** — Kubernetes itself supports
~3 releases (~14 months), and our current approach of backporting
fixes to branches targeting Kubernetes versions that Kubernetes itself
has stopped supporting is inconsistent.

The VEP also includes a two-tier support alternative as a compromise
if the community feels the gap for downstream consumers is too large,
with Tier 1 (3 releases, full upstream commitment) and Tier 2 (next 2
releases, branch remains open but without upstream obligation).

I'd welcome any thoughts, concerns, or alternative suggestions. Even a
quick "this looks reasonable" or "I have concerns about X" would be
very helpful in moving the discussion forward.

Thanks,

Lee