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.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
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.
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
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
r is revision? By the
MAJOR.MINOR.PATCH semver it is the
PATCH. Why not to increase the
PATCH, why to add
r goes after
+? what means
plus, Where it’s place in already present
For the git packages I understand why
lastCommitID but why it needs the
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!