From 751ca2e51d912192e7a1d89f10e21c47268baaf9 Mon Sep 17 00:00:00 2001 From: Davide Principi Date: Thu, 12 Feb 2026 09:58:40 +0100 Subject: [PATCH 1/4] Fix grammatical error in version numbering document --- handbook/version_numbering.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/handbook/version_numbering.md b/handbook/version_numbering.md index b65b6e8..0a7bea6 100644 --- a/handbook/version_numbering.md +++ b/handbook/version_numbering.md @@ -8,7 +8,7 @@ nav_order: 5 The version numbering scheme is a set of rules that define how the version number is assigned to a release. The version number is a sequence of numbers separated by dots, for example, `1.2.3`. -All projects tries to follow the [Semantic Versioning](https://semver.org/) (semver) rules, but there are some differences between the projects. +All projects try to follow the [Semantic Versioning](https://semver.org/) (semver) rules, with some differences between the projects. ## NethServer and NethVoice @@ -53,4 +53,4 @@ OpenWrt roughly follows the semantic versioning rules, but with some differences - do not use pre-release version numbers - do not use metadata version numbers -NethSecurity image versioning is documented [here](https://dev.nethsecurity.org/build/#versioning). \ No newline at end of file +NethSecurity image versioning is documented [here](https://dev.nethsecurity.org/build/#versioning). From ec5d362e306e3289907956e9d7fadf971f1187d4 Mon Sep 17 00:00:00 2001 From: Davide Principi Date: Thu, 12 Feb 2026 10:35:42 +0100 Subject: [PATCH 2/4] Update version numbering guidelines in handbook Clarify version numbering rules and stable release definitions. --- handbook/version_numbering.md | 12 ++++++++++++ 1 file changed, 12 insertions(+) diff --git a/handbook/version_numbering.md b/handbook/version_numbering.md index 0a7bea6..d9911a9 100644 --- a/handbook/version_numbering.md +++ b/handbook/version_numbering.md @@ -18,6 +18,17 @@ syntax is not permitted because the `+` character conflicts with the container image tag specification, as stated in [OCI distribution-spec](https://github.com/opencontainers/distribution-spec/blob/main/spec.md#pulling-manifests). +Since the component version number is for end-users, the choice between +a major, minor, and patch number increment does not strictly follow the +semver rules. + +- Increment major for non-backward compatible releases. Also acceptable + for notable product changes. +- Increment minor for changes like new product features, especially those + visible to the end-user. If the feature also requires a documentation + change or a release note, it is likely to be a minor increment. +- Increment patch in other cases, like bug fixes and internal features. + The distinction between stable and pre-release versions is important in the development process. @@ -33,6 +44,7 @@ the development process. cases, they can be used in production, but only if they address specific bugs requiring immediate resolution. + Releases can be automated using [gh ns8-release-module - GitHub CLI Extension](https://github.com/NethServer/gh-ns8-release-module). ### Update rules From d11bb218fd979abcfac76448d88eaacb2231f3ab Mon Sep 17 00:00:00 2001 From: Davide Principi Date: Thu, 12 Feb 2026 10:43:03 +0100 Subject: [PATCH 3/4] Refine version numbering and update guidelines Clarify versioning rules for major increments and update rules. --- handbook/version_numbering.md | 11 +++++++---- 1 file changed, 7 insertions(+), 4 deletions(-) diff --git a/handbook/version_numbering.md b/handbook/version_numbering.md index d9911a9..b1c6a42 100644 --- a/handbook/version_numbering.md +++ b/handbook/version_numbering.md @@ -23,7 +23,9 @@ a major, minor, and patch number increment does not strictly follow the semver rules. - Increment major for non-backward compatible releases. Also acceptable - for notable product changes. + for notable product changes. If the release introduces a behavioral + breaking change, or it requires a manual upgrade procedure, it is likely + to be a major increment. - Increment minor for changes like new product features, especially those visible to the end-user. If the feature also requires a documentation change or a release note, it is likely to be a minor increment. @@ -50,11 +52,12 @@ Releases can be automated using [gh ns8-release-module - GitHub CLI Extension](h ### Update rules Updates to NS8 core and modules (applications) must follow these rules: -0. New features, enhancements, and bug fixes must not change the behavior + +1. New features, enhancements, and bug fixes must not change the behavior of existing systems. -0. New behaviors must be enabled through explicit and documented sysadmin +1. New behaviors must be enabled through explicit and documented sysadmin actions. -0. Modules must support updates from any previous release within the same +1. Modules must support updates from any previous release within the same major release. ## NethSecurity From 24243d953793b7af0d10251f4cf868975581811b Mon Sep 17 00:00:00 2001 From: Davide Principi Date: Thu, 12 Feb 2026 11:45:12 +0100 Subject: [PATCH 4/4] Apply suggestions from code review Co-authored-by: Giacomo Sanchietti --- handbook/version_numbering.md | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/handbook/version_numbering.md b/handbook/version_numbering.md index b1c6a42..58ed0b9 100644 --- a/handbook/version_numbering.md +++ b/handbook/version_numbering.md @@ -22,14 +22,13 @@ Since the component version number is for end-users, the choice between a major, minor, and patch number increment does not strictly follow the semver rules. -- Increment major for non-backward compatible releases. Also acceptable - for notable product changes. If the release introduces a behavioral +- Increment major for non-backward compatible releases. If the release introduces a behavioral breaking change, or it requires a manual upgrade procedure, it is likely to be a major increment. - Increment minor for changes like new product features, especially those visible to the end-user. If the feature also requires a documentation change or a release note, it is likely to be a minor increment. -- Increment patch in other cases, like bug fixes and internal features. +- Increment patch in other cases, like bug fixes. The distinction between stable and pre-release versions is important in the development process.