Semantic Versioning is not used for a package versions


$ pamac update
To upgrade (4):
  btrfs-progs   5.15-1   (5.14.2-1)  core   862.8 kB


By Semantic Versioning ( in MAJOR.MINOR.PATCH the last group unexpectedly lost. By the specification, all three groups are required.

Already was discussed, but in a bit other context (rcX → release): Why version naming becoming more and more complex? What a reasons to increase its complexity? - #4 by alven

I checked the repos and I saw several other packages which has no .PATCH group in version number.
Is it some lack in version numbering or is it a rejection of semver usage (then what is better and why?)?


1 Like

Arch is using the upstream versioning. Not related to packaging.

1 Like

Why Arch or Manjaro does not fix the errors for their repos?

AFAIK the packages use the versions set by the developers. Ask them.

About btrfs-progs for instance, you can see they do use a patch version… except for .0 .

1 Like

As the Linux kernel does, but it is mistake according to the specification.

There are no errrors to fix.

The version of the package … should be the same as the version published by the author of the upstream software.


Then I would add “…by downstream software authors”.

So, if to follow the Arch rule we need to follow the author’s version numbers unchanged, but then we got misleading version comparison result as was mentioned in the initial post:

To downgrade (1):
  linux515        5.15-1        (5.15.rc6.211018.g519d819-1)  core   102.1 MB

And in that case the solution was to break the rule and to fix it according to the specification to do not mislead users about rcX → release version “downgrade”.

This should be “… by upstream software authors”.
Because the downstream implies that it’s after Manjaro in the distribution chain, but it’s not. It’s the very first part of the software distribution chain, so it’s our upstream and it’s even Arch’s upstream in that regard.

Also, it’s not like that specification is either universal or mandatory…

It should work in 99% of the cases. Of course if the author is using some versioning scheme that would lead to issues, it is up to the packager to make sure that it is changed in a way to make it working properly (obviously).

Btw.: The whole problem with kernel downgrade thing was just a mistake. There shouldn’t have been a . between the minor version and “rc”:

5.15-1 < 5.15.rc <- don't do this
5.15-1 > 5.15-rc <- ok (won’t work; not allowed)
5.15-1 > 5.15rc <- ok
(you can check this with vercmp btw)

There is no need to make it 5.15.0-1 instead of 5.15-1 (if you do x.xrc instead of x.x.rc)
(I see, in the past manjaro has made x.x.0 and x.x.rcX versioning; however you do this, you just need to make sure one is > than the other…)

Why the dash should split both versions:

  1. author’s as them decide what rcX it is;
  2. package build number / overlay number

That produces on on every downstream the situation of double dash: 5.15-rc3-2 where rc3 from the author, and additional 2 from downstream maintainer. Is it a some specification following suggestion? May be better to place full versions?

pacman’s way (Pacman Home Page):

6.0.0 2021-05-20
6.0.0alpha1 2020-12-04
5.2.1 2019-11-01

4.1.0 2013-04-01
4.1.0rc1 2013-03-09
4.0.3 2012-04-07

even w/o dash, which (I think harder to read for humans and for machines - why they did it, I do not know), but it is off-topic, as it is one of some implementation, and could be different from any specification.

Seems dash is not allowed in pkgver nor pkgrel (since it is used to separate them).

So if the author has a version 5.15 release candidate 3, you’d use:


So you’d get 5.15rc3-1

pkgrel is meant for those cases where you need changes to the PKGBUILD itself (e.g let’s say you forgot to install the license file or whatnot) or simply to trigger a rebuild (e.g because underlying libraries changed).


This topic was automatically closed 2 days after the last reply. New replies are no longer allowed.