On Thu, Aug 01, 2019 at 10:14:06AM +0200, Fabio Valentini wrote: > On Thu, Aug 1, 2019 at 9:48 AM Lennart Poettering <mzerqung@xxxxxxxxxxx> wrote: > > > > On Mi, 31.07.19 20:52, Fedora Development ML (devel@xxxxxxxxxxxxxxxxxxxxxxx) 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 _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
