Skip to content
Open
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
24 changes: 19 additions & 5 deletions handbook/version_numbering.md
Original file line number Diff line number Diff line change
Expand Up @@ -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

Expand All @@ -18,6 +18,18 @@ 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. 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.

The distinction between stable and pre-release versions is important in
the development process.

Expand All @@ -33,16 +45,18 @@ 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

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
Expand All @@ -53,4 +67,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).
NethSecurity image versioning is documented [here](https://dev.nethsecurity.org/build/#versioning).