On Thu, Aug 1, 2019 at 9:48 AM Lennart Poettering
<mzerqung(a)0pointer.de> wrote:
>
> On Mi, 31.07.19 20:52, Fedora Development ML (devel(a)lists.fedoraproject.org) wrote:
>
> > Instead, as Lennart explained, systemd has no strong release
> > discipline. systemd didn't provide anyone a fixed version (requiring
> > fishing the fix in its git, and wasting integrator time). And when,
> > finally, systemd makes a new release, it does not even use integrator
> > and automation-friendly semver numbering, but the awful human-oriented
> > rcx labelling, that requires manual mapping to be understood by
> > automation (wasting yet more integrator time).
>
> Hmm? "rc" releases are testing releases, beta releases if you so
> will. They aren't something to deploy in stable distros. They are
> right for rawhide-style distros, and that's where it has been uploaded
> to.
>
> I mean, we don't do semver in systemd, because we only have one stream
> of official releases. However, note that what semver says about
> "pre-release" versions (which is what our rc thing is) is actually
> pretty much in line with what we do:
>
> "A pre-release version MAY be denoted by appending a hyphen
> and a series of dot separated identifiers immediately
> following the patch version. Identifiers MUST comprise only
> ASCII alphanumerics and hyphen [0-9A-Za-z-]. Identifiers MUST
> NOT be empty. Numeric identifiers MUST NOT include leading
> zeroes. Pre-release versions have a lower precedence than the
> associated normal version. A pre-release version indicates
> that the version is unstable and might not satisfy the
> intended compatibility requirements as denoted by its
> associated normal version. Examples: 1.0.0-alpha,
> 1.0.0-alpha.1, 1.0.0-0.3.7, 1.0.0-x.7.z.92"
>
> (Quote from
https://semver.org/#spec-item-9)
>
> So, if you so will, we actually do follow semver on this part. We
> don't follow it on the minor/patch parts, because we only do one stream
> of releases, but on the "rc" part we are actually in line with the
> spec, afaics.
So ... prerelease versions are usually tagged with an "-rc1" suffix
(or similar), which is a valid value for git tags, but RPM doesn't
allow versions to contain hyphens.
In RPM versions, prereleases can be tagged with an "~rc1" suffix (or
similar), which does exactly the right thing for version comparisons
in RPM, but is not a valid value for a git tag.
Since these things are both the case, a simple 1:1 mapping from "-" to
"~" (and even back) is exactly correct.
So I think the systemd.spec is doing exactly the right thing here.
The only issue I see is the arbitrary (?) restriction that git tags
cannot contain the tilde character.
Or is that there for filesystem compatibility, because tags are just files?
That's because '~' means first parent in git-versionspec-lang, and
'~n' means n-th ancestor (in the stright line).
So nnn~1 would mean parent of nnn, and would be ambiguous. nnn~rc1
has no meaning in git, but I still think it'd be madness to allow ~
in git tags.
Zbyszek