mirror of
https://github.com/semver/semver.git
synced 2026-07-10 19:50:47 -05:00
[GH-ISSUE #145] conflict between a hyphen (-) in the version and rpmbuild #4336
No Assignees
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: github-starred/semver#4336
Reference in New Issue
Block a user
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @markgalassi on GitHub (Jul 26, 2013).
Original GitHub issue: https://github.com/semver/semver/issues/145
I decided to use your semver approach in its full glory for a new significant project. I think it's an important thing, and it would be good for people to just adopt it so we don't have so much variability.
I have run in to one problem: I tagged a 0.1.0-alpha.0 release and I also set that to be the version in configure.ac (I'm using automake/autoconf) like this:
AC_INIT([myproject], [0.1.0-alpha.1], [markgalassi@lanl.gov])
unfortunately this brings out an error when I build my tarball myproject-0.1.0-alpha.1.tar.gz and then build an RPM with
rpmbuild -ta myproject-0.1.0-alpha.1.tar.gz
I get this error:
[markgalassi@beachhead _build]$ rpmbuild -ta myproject-0.1.0-alpha.1.tar.gz
error: line 3: Illegal char '-' in: Version: 0.1.0-alpha.1
[markgalassi@beachhead _build]$
I build myproject.spec from a myproject.spec.in file which starts with:
Name: @PACKAGE@
Version: @VERSION@
%define dateNoDashes %(date +"%Y%m%d")
Release: %{dateNoDashes}%{?dist}
and the myproject.spec comes out to be:
Name: myproject
Version: 0.1.0-alpha.1
%define dateNoDashes %(date +"%Y%m%d")
Release: %{dateNoDashes}%{?dist}
This seems to point to a conflict between a rather natural way of doing RPM specs and semver. I wonder how other people have resolved this.
Right now I'm using 0.1.0alpha.1 as the version, but I'd rather stick to semver's spec.
Another option would be to remove the hyphen when generating the spec file.
@robsimmons commented on GitHub (Aug 16, 2013):
Ugh! I would avoid removing the hyphen, as it breaks semvers like 0.1.0-4. A third option would be to replace hyphens with an acceptable alternative that is not allowed in a semver (underscores?)
@david-a-wheeler commented on GitHub (Aug 24, 2013):
I'm having similar problems. If you look at:
http://www.rpm.org/max-rpm/ch-rpm-file-format.html
It notes that in RPM, "the only restriction placed on the version (number) is that it cannot contain a dash".
But of course that means that these version numbers won't work on Red Hat Enterprise Linux, Fedora, SuSE, CentOS, and so on.
I really LIKE the idea of standardized version number conventions, but to be standard they have to work everywhere.
At the least, you could warn people that version numbers with "-" won't work on RPM-based systems. If anyone has a better suggestion that'd be great.
@emonty commented on GitHub (Sep 29, 2013):
Essentially, semver is great, except any software that wants to release and be used on Linux cannot actually directly use it as written :( That makes me a sad pony.
@markgalassi commented on GitHub (Feb 20, 2014):
I have now spent a lot of time researching the topic. I think we risk having even more divergence of versioning approaches with ad-hoc "standards".
The problem is: how do you use semver in a way that both RPM and Debian packages can use without a lot of modification. There is no reason to have more than one way of sorting versions, but it is probably too late to fix that. Still, we can hold ourselves to a subset of possible version strings that both RPM and deb will accept and sort the same way.
If you want that subset to be semver-compatible then the only solution I see is to use ~ (tilde) instead of - (hyphen) for pre-releases (alpha/beta/rc). I will do some experiments on a dummy package, but it seems that both RPM and deb would do the following:
0.2.0
alpha.3 < 0.2.0beta.0 < 0.2.0rc.1 < 0.2.0 < 0.2.0plus < 0.2.1~alpha.0 ...The other approach of not putting the hyphen at all (0.2.0alpha.3) did not work because 0.2.0 sorts to less than 0.2.0alpha.3 in RPM.
@tbull commented on GitHub (Feb 21, 2014):
markgalassi wrote:
I don't seem to get the point. Why is it that you think Semver should
subordinate to the rules of these two specific package systems, even
find a common subset between the two, something which they, apparently,
have never managed to come up with or just didn't feel necessary, while
at the same time ignoring the rules of several dozens other package
systems? What is so special about these two?
See also: https://github.com/mojombo/semver/issues/97#issuecomment-19038801
Apart from that, changing Semver in the suggested manner would be
another breaking change. People would start to ask why a standard, which
is aimed at settling a certain issue once and for all, keeps on
introducing backwards-incompatible changes, thus not settling anything
at all.
@crazedsanity commented on GitHub (Feb 21, 2014):
I'd have to agree with @tbull on this one. There are a lot of places/organizations that impose their own constraints, but that doesn't necessarily make them correct. SemVer should be focused on creating a good, logical standard, not trying to get a standard that works for everything that's already in existence.
If RPM and DEB want to conform to SemVer, that's their choice. Dealing with older packages that aren't compatible with new standards is simply a fact of life, especially when there wasn't a standard to begin with.
@haacked commented on GitHub (Feb 21, 2014):
There is no way for SemVer to conform to every package manager syntax and semantics. That's not the goal. And that's ok.
A standard like SemVer can still benefit package managers that don't exactly follow SemVer's syntax and semantics by using it as a point of standard contrast and comparison.
~instead of a-for pre-release.The point being you don't have to follow SemVer to get some benefit from its existence. Though I think it'd be great if new package managers did.
Of course, this benefit rests on SemVer being widely understood. 😄
@david-a-wheeler commented on GitHub (Feb 22, 2014):
"What is so special about these two?" Wow. Nearly all Linux distributions use either .deb or .rpm formats for packaging. The .deb format includes Debian and Ubuntu. The .rpm format includes Red Hat Enterprise Linux, CentOS, Fedora, and SuSE.
That means that SemVer cannot be used by any of those systems. Any program that might run on them cannot use SemVer directly to specify the version number, either, because SemVer version numbers are incompatible with them. Technically, they can avoid SemVer values on just those systems, but that's a huge pain in the butt - their version number has to change between systems? Nonsense.
In short, as noted above, "any software that wants to release and be used on Linux cannot actually directly use (SemVer) as written". Things like git, Linux, and gcc.
I like the idea of a standardized version format, and I would like to promote one. SemVer, as specified, cannot be that standard. Too bad too, I liked the idea. Maybe someone else will come up with a useful approach instead of SemVer.
@david-a-wheeler commented on GitHub (Feb 22, 2014):
I should hasten to add that you can use simple SemVer numbers no problem, sorry I didn't make that clear earlier.
The problem is that any use of "-" in a version number is just broken.
@markgalassi commented on GitHub (Feb 22, 2014):
I agree with all of the points made here, including the points by people who disagree with me.
Most of all I agree with @david-a-wheeler : almost all packaging is RPM and deb, which would be enough to prompt a minor change to semver's choice of characters from - to ~ (I must still check if ~ works well, but the spec implies it does from RPM 4.10 on; RHEL5 legacy will require kludges).
I like to be a purist, which also has me agreeing with @tbull : semver should propose an abstract standard and others should converge on it. And it sucks that RPM and deb did not agree on versioning: it would have been nice if they had.
Still, I think that the hyphen violates an even older convention, that from the GNU-style tarball. GNU's "make dist" target will build a tarball called PACKAGE-VERSION.tar.gz and the hyphen is clearly a separator between package and version. If you had something like mypackage-1.3.2-beta.2.tar.gz then it would look like the package is called mypackage-1.3.2 and the version is beta.2. Yuck.
Finally: from my survey, I have two possible choices: one is simple kernel-style x.y.z with the odd number convention to mean we are unstable, and thus encoding all pre-releases in that scheme. The other is semver with a ~ instead of a -
I would greatly prefer semver; the "odd number" thing has always struck me as ugly. But the - is a show-stopper.
@Wuzzy2 commented on GitHub (Jul 12, 2014):
Frankly, it’s a bug in rpmbuild then. If they can’t cope with hyphens in version numbers, they have a problem. Hyphens are actually pretty common in version numbers, so there is no good reason for rpmbuild to mess this up.
There is no need for SemVer to change.
@david-a-wheeler commented on GitHub (Jul 12, 2014):
A "standard" that CANNOT BE USED is useless. The "-" cannot be used on nearly all Linux systems as part of a version id. Therefore, a significant part of SemVer cannot be used on nearly all Linux systems.
This is not a bug in rpmbuild, or rpm, or deb. The "-" is forbidden in most Linux packaging systems is because it is a SEPARATOR between the version number and other information (such as the architecture for the given binary). You may not like their convention, but they precede SemVer and will not change for you. There's way too much software already using the standard convention.
SemVer actively violates current standard conventions. SemVer could be useful, or mostly useless. If you want something beautiful but useless, enjoy.
emonty put it clearly : "any software... on Linux cannot actually directly use [SemVer] as written :("
For now, I recommend that people DO NOT USE SemVer. SemVer is in active conflict with practically all Linux's packaging systems, and appears to be unwilling to fix the problem. Too bad. It could have been useful.
@Wuzzy2 commented on GitHub (Jul 12, 2014):
Okay, this is a valid argument. Sad. :-(
@Wuzzy2 commented on GitHub (Jul 12, 2014):
I have thought about this whole thing again.
I have a different idea.
Keep the standard, but use it differently.
Release the software with the “official” version numbering in SemVer.
For specific packages, apply transformations which of course destroys SemVer compatibility; but at least you make the package managers happy.
For RPM-packages, one such transformation could be: “Replace the dash with a period.”.
Therefore, from a practical standpoint, you’d have a software version 5.4.3-alpha and you have a package of that software, which has version 5.4.3.alpha in RPM (and that version number is ONLY the package version for RPM and of course NOT SemVer).
But on the other hand, this is ugly, because it’s the package manager’s job to resolve dependencies.
BUT BUT: The stupid thing is, a lot of version numbers in existance are already not SemVer-compliant (of course they aren’t! We can’t blame them). Even if SemVer version numbers would be compliant with all (or at least all important) package managers, the package managers have none or just little benefit from this, because they can’t use the definition to resolve dependencies the SemVer way. You’d just be mixing “freeform” version numbers with SemVer version numbers. Therefore, to really use the benefits of SemVer, a package manager would also need to know wheather a package uses a SemVer version. Or maybe they even store it as metadata? I don’t know.
For now, even with full compatibility, they can’t tell from a version number wheather it’s SemVer or not.
I think, to be useful, SemVer needs to be somehow adopted by package managers. Without some cooperation with that side, the full potential of SemVer can’t be used. If SemVer tries to bend to every existing package managers, it will just “work”, but without some of the benefits for which SemVer was invented.
Has anyone tried to talk to the RPM or Deb programmers, by the way?
As long no such cooperation exists, maybe we should just seperate between SOFTWARE versioning and PACKAGE versioning. For the same reason package names are rarely identical to the official software names; they are also sooo not standarized and software-specific. It would be crazy to try to standarize the different package names over different packaging systems. Consistent library names in package managers? LOL, forget it!
Likewise, maybe it is simply not even possible to unify version numbering of package managers (I actually don’t know), so we should not try. Maybe just let them keep their own number schemes but don’t endorse the package version numbers as the same as the software version numbers.
This could be used immediately without any changes . But without important benefits like smart dependency resolution as well, as long as there is not a cooperation. At least it still leaves the possibilty open that there is a cooperation later or that some package managers decide to adopt. And when this happened, you can be glad you used SemVer and all you have to do is to update the package version numbers but not the software version numbers.
Another completely different idea involves forking SemVar.
Fork SemVar, call it “SemVar light” (just an example). This would be basically the same as SemVar, but without prerelease and that build (
+) stuff. Just MAJOR.MINOR.PATCH. The set of all possible SemVer light version numbers would be a true subset of the set of all possible SemVer version numbers. In other words: Fully compatible with SemVer.SemVar light could be used immediately in all major package managers without changes (after SemVer light has been formalized, of course!!). Using SemVer light would be “safer” but with less features. When a satisfying solution for the dash debacel is found, SemVer light can be deprecated and SemVer endorsed.
Regardless what is done, I think a cooperation with package manager programmers is needed for using the true potential.
@david-a-wheeler commented on GitHub (Jul 13, 2014):
"SemVer light" is useful, agreed. But there's value in the extras.
A SemVer fork may be the only solution for a fuller feature list.. I really like the idea of SemVer, and almost all its details. The problem is that software can't use SemVer if it runs on Linux or might eventually do so. To me, and many other people, that's a full-stop fail in what is otherwise a great idea.
Would using "~" instead of "-" be enough to make SemVer work in most cases? I'm pretty sure that RPM-based systems accept just about anything EXCEPT "-".
Some version specs, such as Common Lisp ASDF, only permit integers separated by periods:
http://common-lisp.net/project/asdf/asdf.html#The-defsystem-grammar
But I believe they could be extended to allow -, ~, or something else.
@crazedsanity commented on GitHub (Jul 14, 2014):
Moving from one system to the next usually involves a bit of translation. From Debian-based Linux to Redhat (RPM) based Linux to Unix to Windows, there's always translation. There's just no getting around the need for translation.
That being said, why not just replace the dash with an underscore? So "1.2.3-alpha.1" turns into "1.2.3_alpha.1". Using an underscore seems to work a lot better than a dot: underscore can be directly translated backward & forward with a simple substitution; a dot requires making the assumption that the 3rd dot is supposed to be a dash (also, the regex for the translation is super simple).
@david-a-wheeler commented on GitHub (Jul 14, 2014):
Defining a spec that cannot be directly used on common systems is a bug, not a feature. Version numbering should be SIMPLE, not HARD.
Sure, I can replace a dash with an underscore or tilde. But the version numbers have to be consistent everywhere in most of these formats, or if they allow alternatives, you end up doing lots of unnecessary and error-prone patching.
So, what's the best alternative to "-"? Options include:
Both tilde and underscore look a lot like "-", so for people who like their look, those seem to be the most likely alternative.
Are there others preferred, or a reason to choose one over another?
@crazedsanity commented on GitHub (Jul 14, 2014):
@david-a-wheeler I think part of your statement in your first bullet point turned into a font effect. You may want to edit, or re-post, or something, so we get the intended information. Or consider stating what it is in parenthesis.
@vincentbernat commented on GitHub (Jun 4, 2015):
TL;DR: don't use
~blindly. Use~for alpha/beta/rc. Use+for snapshot.I stumbled randomly on this issue and while it is a bit old, maybe I could share some context. As Debian (and I would like to believe this is the same for other systems) packagers, we don't really care about semantic versioning. This is something that should be solved upstream. We only care that version numbers increase with each release.
With RPM format, the only forbidden character is
-because it is the separator with the distribution version (which permits to record packaging changes). With DEB format, the version number can only contain alphanumerics and.,+,-,:,~. So, it is more restricted but the hyphen is allowed. This is because it is not allowed in the distribution version. So, there is a divergence between RPM and DEB. Both of them use the hyphen as separator but RPM considers the first hyphen to be the separation between the upstream version and the distribution version and DEB considers this is the last hyphen. Hence, when we have0.6.3-alpha1.14-1, for an RPM based system, upstream is0.6.3and distribution isalpha1.14-1while on a Debian-based system, it is0.6.3-alpha1.14and1All tools are using the existing convention, so it is absolutely not possible to change it.
However, this was never a problem. Let's say that the upstream version is
0.6.3-alpha1.14. We just transform it manually to0.6.3~alpha1.14. Problem solved for us. We only have a few handful tools manipulating directly the upstream version, so this is not a problem (one of those tools isuscanwhich tells if there is a newer version available. For that, it needs to mangle the upstream version with a regex).As I said before, the most important point for us is for the versions to be correctly sorted. So, replacing hyphens by another sign should not be done blindly. For alpha/beta/rc, we use
~because it orders before any other characters even the "no" character. So,0.6.14~alpha1<0.6.14~alpha2<0.6.14~beta1<0.6.14. On the other hand, when the version is a snapshot, we must ensure that the order is also correct, so it is0.6.14<0.6.14+git20150604+5(assuming there is 5 commits since 0.6.14) <0.6.14+git20140504+6. We don't really have a convention for this. The only point is to ensure that versions are always increasing.If we make an error, we can reset everything by using an epoch (this is specific to DEB, I think there is no such thing for RPM). Suppose we have released
0.6.14-alpha1-1and0.6.14is released. We cannot package it as0.6.14-1(which is inferior), so we use1:0.6.14-1. But this is really a last resort solution because if another package requires< 0.6.15,1:0.6.14-1wouldn't match.@Wuzzy2 commented on GitHub (Jun 4, 2015):
Maybe we should consider RPM package version numbers to be more or less independent of the actual software versions; the packages use their own versioning system but packagers seem to try hard to come as close to the original version number as possible.
If we view it this way, then it is no problem that RPM package versions may not perfectly map to the actual software version.
I suppose SemVer-based software is by far not the only software of which its version number can't be perfectly translated into a RPM version number. The hyphen is a common character in software versions anyways.
@lukeyeager commented on GitHub (Oct 22, 2015):
I'm with @tbull - keep SemVer pure and strict. Don't change it.
I'm with @Wuzzy2 - follow SemVer in your project, and follow it as closely as possible when dealing with package mgmt.
To add some more information to this discussion, debian packages have no problem with a version like
0.14.0-beta-1.upstream_versionis correctly parsed as0.14.0-betaanddebian_revisionis correctly parsed as1. The problem is when you try to use a version like0.14.0-beta.1-1:The versions are still parsed correctly, but they are sorted incorrectly. Lintian helpfully lets you know that this is going to be a problem.
Switching the version to
0.14.0~beta.1-1for the debian package and suppressing thepackage-name-doesnt-match-sonameswarning solves my problem. I'm not overly worried about the debian package version for a pre-release not matching my project's semantic version exactly.@jasonmp85 commented on GitHub (Mar 11, 2016):
I came across this thread while researching the subject and wanted to drop my proposals here.
I'm going to number the project in question in a way compliant with semver. Everywhere possible (git tags, certain packaging systems, the version reported by the software itself, etc.), I'll use the compliant semver version formulation.
But in the
.deband.rpmI have to make concessions to those systems. In particular, it's easy enough for a.debto have version1.0.0, but for2.0.0-rc.1, I'll use2.0.0~rc.1. This mapping is bijective.Similarly, in
rpm, I can't have any separator other than a period. Again, perfectly fine for stable releases, but for prerelease versions, they say to use the release field. So2.0.0-rc.1will instead becomeVERSION=2.0.0andRELEASE=0.1.rc.1(in particular, I plan on doingRELEASE=0.<n>.rc.<n>for release candidate n).Since I generally only have stable releases and release candidates (names like "alpha", "beta", etc. are avoided), this solution works fine. I'll have to think about nightly/snapshot releases at some point in the future, but thought I could post my solution here in case any else hits here via Google.
@ghost commented on GitHub (Nov 30, 2016):
Use of the RELEASE field as @jasonmp85 describes above for RPMs seems like it might be on it's way to being "correct", but I needed a pragmatic alternative since we already have an internal standard for the RELEASE field.
Using the following progression from semver.org:
1.0.0-alpha < 1.0.0-alpha.1 < 1.0.0-alpha.beta < 1.0.0-beta < 1.0.0-beta.2 < 1.0.0-beta.11 < 1.0.0-rc.1 < 1.0.0
I created RPM's for equivalent versions of each of these, replacing - with ~. The only one that did not install (trump a previous install) was 1.0.0-alpha.beta.
Therefore, from a pragmatic perspective, replacing the dash with the tilde works well, but it does not cover SemVer cases where a secondary alpha/beta is being used.
@jwdonahue commented on GitHub (Dec 2, 2017):
@markgalassi
My two cents: Implementation specific mappings between SemVer and other schemes are not strictly ruled out by the SemVer spec, provided the SemVer version of the version string can be readily acquired, either by lookup or conversion. I have used this approach to create path names to "package" directories in the past and I can't see any reason why it wouldn't work with inflexible package managers as well.
It seems the spec was not altered and there is little chance of your requested changes being accepted. Unless you intend to provide PR for this issue, please close it at your earliest possible convenience.
@silkentrance commented on GitHub (Dec 7, 2017):
@markgalassi autoconf is what you want to renovate. not the other way around. otherwise, indirection is your friend.
@jwdonahue please close this regardless.
@david-a-wheeler commented on GitHub (Dec 7, 2017):
The system package managers and build sysyems are unlikely to be changed. A simple solution is to allow tilde (~) or underscore (_) as a separator in SemVer for this kind of information.
@grv87 commented on GitHub (Apr 29, 2018):
Some devops tools allow usage of
-in the names or versions but prohibit+. For example, Amazon AMIs, VirtualBox VMs or Vagrant boxes. So I substitute_instead of+to denote build metadata (namely, architecture e.g.amd64).I wish there would be no overlapping changes in standard so that
_would suddenly become used for prerelease. I think deviations in delimiters should be left for particular implementations of semver and not be a part of the standard.Maybe to avoid such issues the standard could use abstract
prerelease delimiterandbuild metadata delimiterterms and include section about reference/default implementation instead which could specify old default/recommended delimiters.@jwdonahue commented on GitHub (Oct 7, 2018):
@markgalassi, can you please close this issue at your earliest possible convenience. I don't have the sauce and we're trying to reduce number of none actionable issues. Thank you.
@alexandrtovmach commented on GitHub (Jun 10, 2020):
This issue looks staled and will be closed in 10 days if there are no objections. Thanks everyone for contribution, you're amazing 🎆
@david-a-wheeler commented on GitHub (Jun 10, 2020):
I object.
It isn't really stalled. It is ignored. Linux is extremely popular, with red hat and Ubuntu and so on all using package managers that do not like hyphens in version numbers. Linux use has increased over time, especially on servers. Semver unnecessarily causes problems for a large number of real users. Several actionable l solutions have been briefly discussed above, but ignored. Let's solve the problem, not ignore it.
@ljharb commented on GitHub (Jun 10, 2020):
It seems like solving the problem means fixing those tools?
@david-a-wheeler commented on GitHub (Jun 10, 2020):
One solution, for example, is to allow tilde instead of dash for this case. I imagine there are other solutions.
@markgalassi commented on GitHub (Jun 15, 2020):
That's what I had proposed. I recommend it in my article on release
engineering. Works well with RPM but it seems to be a bit annoying for
debian.
@alexandrtovmach commented on GitHub (Jun 15, 2020):
Thank you guys for continuing discussion, for now I'm only remove
staledlabel, but a bit later will join your chat 👍@jbigot commented on GitHub (Jan 23, 2021):
From my point of view, there is no way to have a single standard to rule them all that would work everywhere. The approach that would seem correct to me would be to:
Then, it would be possible to add additional concrete syntaxes for systems that do not accept the default one, for
.deb, it would for example be a simple question of using a tilda istead of a dash (an underscore would result in incorrect ordering).@david-a-wheeler commented on GitHub (Jan 25, 2021):
@jbigot - it would have been possible, but that's neither here nor there.
Defining a standardized mapping would be a good thing, that would probably resolve it.
@Conan-Kudo commented on GitHub (Feb 17, 2021):
RPM's versioning rules are as follows:
a-zA-Z), digits (0-9) and separators (._+~^)~) and Caret (^) are special separators and have special meaning/handling1+0 == 1.0a < 1a (97) > A (65)1.1 < 1.10,1.0 < 1.0.0~) makes version sort lower -1.0 > 1.0~,1.0 > 1.0~rc1^) makes version sort higher -1.0 < 1.0^,1.0 < 1.0^post10) after separator handled natively -1.0 == 1.000@alexandrtovmach commented on GitHub (May 14, 2021):
closing in favor of https://github.com/semver/semver/issues/703#issuecomment-841420754
@gh-andre commented on GitHub (May 30, 2021):
Interesting thread. Long one too. A few comments above describe that translation is needed between semver and package versioning, but stop short of saying (unless I missed any) that while semver and package versioning intersect in some aspects, they actually represent two different concepts and there's no selection of punctuation that can "fix" that in a way that semver can be used verbatim in package names.
Semantic Versioning describes the level of change in the upstream software and works outside of any package versioning. That's what the upstream software may print when
--versionis used. Package managers like RPM are meant for packaging upstream software and need to accommodate a large spectrum of upstream versioning schemes to sort package versions properly within their very diverse ecosystems.Package maintainers are often different from upstream software maintainers and may need to repackage same version of upstream software, which may happen without any code changes (e.g. use different compiler flags) or because they introduced a patch on top of the patch level in the upstream software. That patch may be submitted back to upstream maintainers and may or may not make it into the software patch level. Both are patch levels, but they are not quite the same kind of a patch conceptually.
Semver works great for software versioning, but when used as a package version, will limit packages to contain only changes from the upstream software maintainers. NPM is like that - all changes must come from software maintainers because there is no way to accommodate repackaging, snapshots and 3rd-party patches. It works out for NPM, but not quite so for Nuget, which has many packages created by 3rd-party package maintainers, but offers no way to repackage same software because it lacks package revisions.
Semantic versions simply need to be translated for packaging and if a build pipeline produced an artifact
myapp-1.2.0-beta1+045.tar.gz, it may be packaged asmyapp-1.2.0-0.1.beta1.el8.rpm, may be repackaged without any upstream source changes asmyapp-1.2.0-0.2.beta1.el8.rpmand, when upstream changes, packaged asmyapp-1.2.0-0.3.beta2.el8.rpm. None of these package version variations takes away from the semantic meaning of the enclosed software version.