Skip to content

Commit f06867d

Browse files
authored
Merge pull request #1087 from SergeyKanzhelev/versioning-proposal
docs: Add versioning proposal
2 parents f054f44 + b132355 commit f06867d

File tree

1 file changed

+37
-0
lines changed

1 file changed

+37
-0
lines changed

docs/versioning.md

Lines changed: 37 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,37 @@
1+
# Versioning Scheme for Node Problem Detector
2+
3+
This document describes the versioning scheme for the Node Problem Detector, which is designed to align with Kubernetes releases.
4+
5+
## Versioning Scheme: `v1.<k8s_minor>.<patch>`
6+
7+
The versioning scheme is `v1.<k8s_minor>.<patch>`.
8+
9+
* **v1**: The major version is 1, indicating the project is considered stable.
10+
* **`<k8s_minor>`**: This part of the version is the minor version of the supported Kubernetes release. For example, for Kubernetes v1.34, this would be `34`.
11+
* **`<patch>`**: This is a patch number for bug fixes and other small changes within the same supported Kubernetes version.
12+
13+
For example, for Kubernetes v1.34, the corresponding version of the Node Problem Detector is in the `v1.34.x` series. The first release for this Kubernetes version would be `v1.34.0`.
14+
15+
The release branch is named `release-1.<k8s_minor>` to match Kubernetes versions (e.g. `release-1.34`). Git tags are named after the version, like `v1.<k8s_minor>.<patch>`. Patches are created from these release branches.
16+
17+
This scheme is not ambiguous and will work for the foreseeable future. Kubernetes v1.100 is not expected until approximately 2047.
18+
19+
## Reasoning
20+
21+
This versioning scheme provides the following benefits:
22+
23+
* **Clarity**: It is immediately clear which version of Node Problem Detector is compatible with which version of Kubernetes.
24+
* **Consistency**: It aligns the project with the release cycle of Kubernetes and some other Kubernetes components versioning.
25+
* **Predictability**: Users can better predict when new releases will be available.
26+
* **Easier Maintenance**: By having separate version lines for each Kubernetes minor version (e.g., `v1.34.x`, `v1.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.
27+
* **Targeted Testing**: Each version of Node Problem Detector is tested against a specific Kubernetes version. This also implies testing against particular versions of related components like the container runtime and OS. New features in Node Problem Detector will not necessarily be tested against older versions of these components.
28+
29+
## Previous Versioning Scheme
30+
31+
For reference, the previous versioning scheme was `vX.Y.Z`.
32+
33+
* The major version `X` was always `0`.
34+
* The minor version `Y` was incremented for releases with significant new features.
35+
* The patch version `Z` was used for smaller features and bug fixes.
36+
37+
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-0.8` so we can keep track of changes that are used as hotfixes for `0.8.21` and below releases.

0 commit comments

Comments
 (0)