Introduce a branching model for vulnerability fixes

[wangzhen127]

Currently NPD has only one master branch. When making new releases, we just tag the latest commit and make a release from that. The problem with this model is that every new release includes both vulnerability fixes and new features. Sometimes we want to backport vulnerability fixes but not features, to minimize the risk to production. Ideally, we should have a branching model similar to https://github.com/kubernetes/kubernetes. That is, we need to introduce minor versions to NPD releases. Features only go to master branch and new minor releases. Vulnerability fixes and bug fixes go to master branch first, and can be backported to previous minor versions.

[wangzhen127]

CC a few folks who may be interested at this. @hakman @daveoy @DigitalVeer @AnishShah @SergeyKanzhelev

[SergeyKanzhelev]

Per-minor release of NPD sounds as a great plan.

[daveoy]

Happy and excited to help with this

[wangzhen127]

Happy and excited to help with this

@daveoy Do you plan to have a proposal? 😃

[chrishenzie]

Do we have automation to manage the creation of release branches in other k8s repos? It seems like a good starting point would be to watch for branch cuts in k8s/k8s and create them here.

[SergeyKanzhelev]

Proposal: New Versioning Scheme for Node Problem Detector

This document proposes a new versioning scheme for the Node Problem Detector to align more closely with Kubernetes releases.

Current Versioning Scheme

The current versioning scheme is vX.Y.Z, where X, Y, and Z are major, minor, and patch versions respectively. This does not reflect the project's dependency or compatibility with Kubernetes versions.

Proposed Versioning Scheme: v0.<k8s_minor>.<patch>

The proposed new versioning scheme is v0.<k8s_minor>.<patch>.

• v0: The major version will remain 0, as we are not ready to declare the project as stable.
• <k8s_minor>: This part of the version will be the minor version of the supported Kubernetes release. For example, for Kubernetes v1.34, this would be 34.
• <patch>: This is a patch number for bug fixes and other small changes within the same supported Kubernetes version.

For example, with the release of Kubernetes v1.34, the next version of the Node Problem Detector would be v0.34.0.

This scheme is not ambiguous and will work for the foreseeable future. Kubernetes v1.100 is not expected until approximately 2047.

Reasoning

This new versioning scheme will provide the following benefits:

• Clarity: It will be immediately clear which version of Node Problem Detector is compatible with which version of Kubernetes.
• Consistency: It aligns the project with the release cycle of Kubernetes, which it is tightly coupled with.
• Predictability: Users can better predict when new releases will be available.
• Easier Maintenance: By having separate version lines for each Kubernetes minor version (e.g., v0.34.x, v0.35.x), we can easily backport critical bug fixes and CVEs to older, still-supported release lines without being forced to also backport newer features.

Implementation

To implement this change, we will:

1. Update version.txt to the new version format.
2. Update the release process documentation in docs/release_process.md.
3. Update the hack/tag-release.sh script to handle the new versioning scheme.

[SergeyKanzhelev]

@chrishenzie @wangzhen127 are you OK with this version bump?

[chrishenzie]

Will this mean this repo will maintain release-$K8S_VERSION branches from which to cut these releases, and if so, how/when will they be cut?

we are not ready to declare the project as stable

It seems like this project has been around at least 8+ years and (presumably) ran in many different prod environments. What are the gaps preventing us from calling this "stable"?

[SergeyKanzhelev]

Will this mean this repo will maintain release-$K8S_VERSION branches from which to cut these releases, and if so, how/when will they be cut?

Yes, this is a proposal. This way we will have more freedom to "mess up" with master.

What are the gaps preventing us from calling this "stable"?

We can list some requirements and when ready switch to 1.0. I don't think abybody went thru this exercise and it well may be just a documentation issue. But I want to detach this from versioning change

[SergeyKanzhelev]

I suggest we implement this change, branch out 1.34 and then we will start accepting more features.

[daveoy]

Let me know how I can help

[SergeyKanzhelev]

Do we need to create a branch for release-pre-1.34 so it can be used as a "master" for hotfixes for versions 0.8.21 and earlier? Added to #1087