[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

[Lee Yarwood]

Following up on this thread — VEP #233 has now been merged and I
wanted to share an update on next steps.

# Immediate step: archive dead release branches (release-0.4 through
release-0.57)

As a first step under the VEP's transition plan [1], @dhiller has put
together a draft PR to archive the 50 release branches from
release-0.4 through release-0.57:

https://github.com/kubevirt/project-infra/pull/5041

These branches have been de facto dead for years, none receive
backports, and many target Kubernetes versions that Kubernetes itself
stopped supporting long ago. The PR:

- Removes 25 presubmit CI job YAML files for release branches
0.13-0.57 (~33,400 lines of dead config)
- Opts all 50 branches out of the Prow branchprotector so that they
can be locked
- Cleans up stale config entries for branches that were never created
(release-0.25, release-0.28)

After the PR merges, a follow-up script will set lock_branch: true on
all 50 branches via the GitHub API, making them fully read-only. No
branches or tags will be deleted; they remain as a historical record.

To give downstream users and vendors time to react, we will hold off
on merging this PR until v1.9.0-beta.0 (May 21, 2026) [3]. If you are
relying on any of these branches, please raise this on the thread
before then.

Note that release-0.58 and release-0.59 are out of scope for this
initial cleanup — they will be handled by the normal EOL trigger at
v1.10 GA.

# The longer plan enforcing a 3-release support window

The broader goal of VEP #233 is to adopt a hard EOL policy modeled on
the Kubernetes patch release support period [2], limiting active
maintenance to the 3 most recent minor releases. With 3 releases per
year, this provides approximately 12-15 months of support per release.

The timeline is:

1. v1.9 GA — Policy announced
2. v1.9 to v1.10 — Grace period of one full release cycle for the
community and downstream consumers to prepare
3. v1.10 GA — Policy enforced. All releases older than N-2 are marked
EOL (v1.7 and earlier). Branch protection applied, CI lanes removed,
and cherry-pick PRs targeting EOL branches auto-closed with a message
directing users to upgrade.

Going forward, each new GA release will automatically trigger EOL for
the N-3 release (e.g., v1.10 GA -> v1.7 EOL, v1.11 GA -> v1.8 EOL).

For the full rationale, CVE backport analysis, and alternatives that
were considered (including a two-tier support model for downstream),
please see the VEP:

https://github.com/kubevirt/enhancements/blob/main/veps/sig-release/233-release-branch-eol-policy/vep.md

Feedback welcome on this thread or on the archive PR.

Cheers,

Lee

[1] https://github.com/kubevirt/enhancements/blob/main/veps/sig-release/233-release-branch-eol-policy/vep.md#transition-plan
[2] https://kubernetes.io/releases/patch-releases/#support-period
[3] https://github.com/kubevirt/enhancements/pull/305