Starting on August 2017, the YaST team adopted a new versioning schema to be followed by packages included in SUSE Linux Enterprise (SLE) 15 and openSUSE Leap 15, beyond.
If you are interested in the old schema, which is still used for SLE 12 and openSUSE Leap 42.x, have a look at the Old schema section of this document.
New schema: version numbers are related to SUSE versions
From now on, version numbers will be related to the SUSE version. Let's see an example:
- Major number is related to the major SUSE version (4 for SLE 15, 5 for SLE 16, and so on).
- Minor number is related to the SUSE Service Pack number (0, 1, 2...).
- Patch number enumerates versions for a given major/minor version.
4.2.3 is meant to be the fourth version which is specific to SLE
Note that it is perfectly fine if, let's say SLE 15 SP2, contains a package
which version is
4.1.1. It means that the package has not been changed since
SLE 15 SP1 times.
When to bump each number
Basically, these are the rules when it comes to increase version numbers:
- Every fix/change that goes as a maintenance update should increment the
patch number (
- The first commit that introduces a divergence between the
masterand the latest SP branch (for instance
SLE-15-SP2) should increment the minor version.
- The first commit that introduces a divergence which is meant to be only available in the next major SUSE release should increment the major version.
The best way to understand how versioning works is through an example. Let's
say SLE 15 (SP0) was already released and let's say there is a package
yast2-example which version is
4.0.0. Moreover, there is a
in the repository.
- A regular fix increases the version to
4.0.1. Of course, that change is merged into
masterbut keeping the same number as far as the package has not diverged.
- Then a new change which is meant for SLE 15 SP1, but not desired for SLE 15
(SP0), is added to the
masterbranch. So the package has diverged and the minor version should be increased (
- Another fix for the already released version appears.
SLE-15version is now
- Fast forward: SLE 15 SP1 is about to be released and a new
SLE-15-SP1branch is created (keeping version
- A fix for
SP1increases version to
4.1.2. The change is merged into master.
- A fix for
SLE-12-SP1version) increases version to
The resulting scenario should be:
Fast forward again: SLE 15 SP4 is under development. But
yast2-example has not
changed since SP2 times, so its current version is still
- Then a fix for
mastercomes in. As this fix is intended for SP4 and introduces a divergence with SP2, we should bump minor and patch numbers to
4.4.0. Note the correspondence between minor number and the SP number.
Of course, when SUSE Linux Enterprise 16 arrives, the first change that
introduces a divergence with last SLE 15 version should increase version
Let's summarize the current situation:
master(already targeting SLE 16): 5.0.0
Finally, what happens if a bug is fixed for
SLE-15-SP3 (and newer versions)?
The change introduces a divergence between
minor number should be increased:
master(already targeting SLE 16): 5.0.1
Increase the patch number
The old schema is still valid for SLE 12 and openSUSE Leap 42.x. The general rule is to bump only the patch number and, if needed, add a fourth one to avoid conflicts.
Major and minor versions are only incremented under team agreement. For
instance, the minor number was changed when CaaSP development started and,
again, after branching
SLE-12-SP3 (which was about to be released in that
About the major version, it was reserved for big changes in YaST world, like migrating from YCP to Ruby.
Following this schema we can face a tricky situation. Consider this scenario:
yast2-example repository contains these branches:
SLE-15-SP1: 3.3.2 (this branch contains a new feature)
If we want to release a fix for
SLE-15, we cannot just bump the patch number,
because 3.3.2 already exist and contains different code. The solution is to add
a fourth number to the
SLE-15. In this case, it would be 220.127.116.11.
This new digit will be incremented with every new version on that branch (18.104.22.168, 22.214.171.124, etc.) avoiding any possible conflict in the future.