Why version naming becoming more and more complex? What a reasons to increase its complexity?

Support Software & Applications
1
  1. May be someone have a strong knowledge what’s the difference in the version of the package?

Update log excerpt:

...
To upgrade (1):
  qt5-wayland  5.15.2+kde+r30-1.0  (5.15.2+kde+r30-1)  extra  1.5 MB

Total download size: 1.5 MB
Total installed size: 61.4 kB
...

What that package is dedicated for:

$ pacman -Qi qt5-wayland | grep Desc
Description     : Provides APIs for Wayland

  1. Generally, what’s the difference if version change from 1.1.1 to 1.1.1.0?

  2. Whats the diff if build number changed from -1 to -1.0?

  3. Why even builds number got a fraction instead of simple increment by 1: -1, -2, -3, etc.

  4. How to automate a parsing of such mess, which becoming more and more complicated and unpredictable?

  5. Why to increase complexity instead if using of simpler semver.org? Not enough powerful version naming? Not enough for what purposes?

What the hell is going on with version naming? It became more and more less systematized, less ordered. Plus signs, a few pluses, build number via dot(s). What’s next? When someone adds an emoji into version name? What tasks does it solve, which not covered by semver?

2

? nothing new with arch/pacman

here is a git package: release + patch in git repo
release+kde+(more)commitCount
it’s not a problem, all this is the version (parse what ? [epoch:]all before last “-” is version)
as here release+commitCount+lastCommitID

zenity 3.32.0+55+gd7bedff-1
xdg-utils 1.1.3+19+g9816ebb-1
sdl 1.2.15+387+gfbfcca32-1

parse for compare version ? exists alpm.vercmp(), is you not use C, it’s easy to rewrite in other language and command vercmp in pacman package

EDIT: yes, pkgrel with sub version is manjaro specific
manjaro-release 21.1.4-1.0 - hunspell-pt_br 3.2-5.0 - mprime 298b6-1.0 - taglib-extras 1.0.1-7.0

2 Likes
3

That means it’s a temporary overlay on top of the Arch package. When Arch updates even just the pkgrel say to 2, we’ll know there’s a newer version and either remove our overlay or update ours accordingly.

https://wiki.archlinux.org/title/PKGBUILD#pkgrel

EDIT: It’s a potential fix for this upstream issue:

Arch bug report: FS#72155 - [egl-wayland] Black screen in Plasma Wayland

Please edit your topic title to be more clear and concise.

2 Likes
4

Another example:

pamac update
Preparing...
Synchronizing package databases...
Refreshing core.db...                                                                                                                                                                        
Refreshing extra.db...                                                                                                                                                                       
Refreshing community.db...                                                                                                                                                                   
Refreshing chaotic-aur.db...                                                                                                                                                                 
Warning: linux515: downgrading from version 5.15.rc6.211018.g519d819-1 to version 5.15-1                                                                                                     
Resolving dependencies...
Checking inter-conflicts...

To upgrade (5):
  mpd             0.23.3-1      (0.23.2-1)                    extra  876.0 kB
  openmpi         4.1.1-3       (4.1.1-2)                     extra  3.4 MB
  python-gobject  3.42.0-1      (3.40.1-2)                    extra  257.6 kB
  re2             1:20211101-1  (1:20210901-1)                extra  178.3 kB
  zenity          3.41.0-1      (3.32.0+55+gd7bedff-1)        extra  3.1 MB
To downgrade (1):
  linux515        5.15-1        (5.15.rc6.211018.g519d819-1)  core   102.1 MB

Total download size: 110.0 MB
Total installed size: 5.4 MB

Apply transaction ? [y/N]

Upgrading from beta (rcX) to release version auto-interpreted as downgrade.

5

OK, we checked regarding linux515, package versioning. Seems to be correct. We will release a 5.15.0 update to fix this, including some fixes to compile some more extramodules …

1 Like
6

… or 5.15 should have a full name of 5.15.0 like https://semver.org/ suggests.
For example new pacman version was not named as 6 or 6.0, it has full name of 6.0.0 (Pacman Home Page)
not a shortened versions.

In human-only related descriptions logs that could be shortened as any v6, 6, or Pacman Home Page :

Version 4.0 added package signing and
Version 5.0 added support for

but not in tech info of a package specs, which has strong(er) semantics of versioning and designed to be as much easy as could be, but in the same time to classify all changes which got a package.

Generally the topic was started by me probably in inappropriate place: if versioning inherits from Arch, and probably Arch inherits it from external source, it is global problem and not related to the single package (where I can submit an issue report to) but I see several packages of different developer (or developer groups) which has that lack.

So that topic is mostly off-topic: upstream lacks. :unamused:

in this example the kde should be in the name of a package, not in version of course.
The first versioning edit should be at least

qt5-wayland  5.15.2+kde+r30-1

→ 

qt5-wayland-kde  5.15.2+r30-1

cause kde is not a version, it is a type of a package: it will never be updated from a 5.15.2+kde to a 5.16.0+gnome, so the kde is a version unrelated group, but erroneously present in a version field.
thanks god we do not have a

my-terminal-emulator 2.1.1+kde
my-terminal-emulator 2.1.1+gnome
my-terminal-emulator 2.1.1+i3
my-terminal-emulator 2.1.1+xfce

The r is revision? By the MAJOR.MINOR.PATCH semver it is the PATCH. Why not to increase the PATCH, why to add r instead?

Why r goes after +? what means plus, Where it’s place in already present . and - hierarchy?

For the git packages I understand why lastCommitID but why it needs the commitCount also?
Why any small groups of commits does not increase the PATCH of a package if you are patching an app? 55 commits w/o a patch increase? It is crazy.
By git basics the development process goes not in a master, so developer can do any count of commits to do a complete patch of some functionality, but after the patching done and merging with the master branch is done, the PATCH number should be increased, no any +r55 to add - is it redundant, the PATCH filed is for that. I see only that me or a developer did not undetstand the semver and trying to add redundant sections of versioning which duplicated an already existed ones.

Yeah, that’s overlays was not covered by semver. semver is intended to be used for initial developer releases. That how why I understand a “build”/overlay number.

While we see that my topic mostly addressed to upstream version naming, I ask Manjaro team to be closer to version naming standard(s?) as much as we can do it: it is not a suggestion to convert qt5-wayland 5.15.2+kde+r30-1 comes from upstream to a bit more properly named of qt5-wayland-kde 5.15.2+r30-1, but it is am ask to do not add an redundant version groups/garbage on our side.
That’ to only point I want to ask Manjaro team.

Yeah, globally present naming issues I should discuss in global forums, not on a specific OS forums.
My fault to issue the global software related topic here.

But thank you for listening to me and that you did fixes related to Manjaro side!

7

You should probably discuss that with the kernel guys :wink:
For first release of a new kernel series, they always omit the .0

image

Arch follows the version of the author of the software (and so does Manjaro)
If you don’t like their (the author’s) versioning scheme you’d need to contact them instead…

1 Like
8

It is the omit for a human-readable descriptions like https://www.kernel.org/ or git’s badges/tags like Release v5.15 · torvalds/linux · GitHub or is it somewhere inside of the kernel’s code also, which makes some system calls for example uname -r to show only shortened 5.15?

If only in description, it is a simplification for a human reader only, and has nothing to do with technical specs.

Yeah, generally we see that most issues I touch comes from upstream, and if Manjaro team goes against the upstream kernel versioning issues like 5.15 to make a proper semantic fix to 5.15.0 I can only be glad so much that the team fixes it.

9

I meant the kernel homepage (but yes, they also do it with their git tags).
In their makefile they have:

VERSION = 5
PATCHLEVEL = 15
SUBLEVEL = 0
EXTRAVERSION =
NAME = Trick or Treat

Of course when you build / package the kernel you can do whatever you’d want and call it “my super kernel V1000-extra-hot” (which you could display with uname -r)

1 Like
10

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