[TRACKING] Define Project Versioning, Compatibility, and Release Playbook

[vitorfloriano]

As node-readiness-controller matures (currently v0.3.0), we need a formalised structure for versioning and support to provide stability for our users and a clear roadmap for contributors. This issue tracks the creation and documentation of our versioning strategy.

We need to do things like:

• Draft Versioning Policy: Define Semantic Versioning (SemVer) usage.
• Establish Support Lifecycle: Define how many minor versions we support (e.g., N-2).
• Create Compatibility Matrix: Document the mapping between Controller versions and Kubernetes versions.
• Write Versioning Playbook: Standardise the release process (tagging, CI, changelogs).
• Publish Documentation: Add /docs/VERSIONING.md and update README.md.

Relates to #151

[TBD - this must be discussed with maintainers first]

[sahitya-chandra]

Hey @vitorfloriano, is it possible I could collaborate on this issue with you?

[vitorfloriano]

Hey @vitorfloriano, is it possible I could collaborate on this issue with you?

Hi @sahitya-chandra

I think this needs to be throroughly discussed with the maintainers, preferrably in a meeting, before we take any actions. I'll update the description.

[sahitya-chandra]

Agreed with the discussion part, I also thought that this is a pretty big issue, so I could help you in some way with it :)

[vitorfloriano]

@sahitya-chandra there's also a thread on Slack, if you're interested in following the discussion. 🧵

[Priyankasaggu11929]

(follow up from yesterday's (May 13, 2026) project meeting discussion)

I would still like to continue this discussion in the next project meeting, so we can collect more opinions from other maintainers as well (especially @ajaysundark), around what signals/criteria we want to use for defining our compatibility matrix eventually.

Because I feel the same CI signals/criteria will majorly help us towards the near term high priority item - of defining API graduation (and maintenance) criteria for the NRC controller.

Meanwhile - the work for migrating our CI jobs to prow will be helpful to establish some preliminary set of CI signals - #210 (comment)

---

Also just for record keeping - below are some references from the NPD project (around establishing support matrix):

• https://github.com/kubernetes/node-problem-detector/pull/900/files
• Introduce a branching model for vulnerability fixes kubernetes/node-problem-detector#1062
  Especially the part - Introduce a branching model for vulnerability fixes kubernetes/node-problem-detector#1062 (comment)

[Priyankasaggu11929]

One concrete thing we can mention in the comptability matrix is that

NRC requires Kubernetes >= v1.25, since it relies on CRD x-kubernetes-validations (CEL) for enforcing immutability of the NRR CRD fields, and for validating taint key format & allowed values.

Also, when PR #117 merges, the minimum kubernetes version requirement for the MAP (Mutating Admission Policy) based daemonset auto-toleration functionality will be >= v1.32 (MAP turned beta, and on-by-default in v1.32).

[vitorfloriano]

Another thing to consider:

Constrained Impersonation (KEP-5284). I mean, if we want to harden security by default, shouldn't we strongly suggest that feature to be on? If so, wouldn't that push the minimum recommended k8s version to v1.35/v1.36?

xref: kubernetes/enhancements#5284 (comment)
xref: #143

[ajaysundark]

@vitorfloriano Constrained impersonation (or even using the readiness-reporter component) is not a requirement for NRC as the controller relies only on core k8s API like Taints..

What we could focus on is creating a test grid, validating our core e2e cases across the k8s/kind versions (1.31+). This matrix should be release blocking for us. I'm hoping we could find time to attend these Release reliability improvements during the upcoming LFX term.