docs: Add versioning proposal

Author: SergeyKanzhelev

docs/versioning.md

@@ -0,0 +1,47 @@
+# 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`.
+
+The release branch will be named `release-1.<k8s_minor>` to match Kubernetes versions (e.g. `release-1.34`). Git tags will be named after the version, like `v0.<k8s_minor>.<patch>`. Patches will be created from these release branches.
+
+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.
+
+## Previous Versioning Scheme
+
+For reference, the previous versioning scheme was `vX.Y.Z`.
+* The major version `X` was always `0`.
+* The minor version `Y` was incremented for releases with significant new features.
+* The patch version `Z` was used for smaller features and bug fixes.
+
+This model did not provide a clear link to the supported Kubernetes version, making it difficult for users to determine compatibility. We will have a branch named release-pre-1.34 so we can keep track of changes that are used as hotfixes for 0.8.21 and below releases.