[sane-devel] Version numbering (was Re: Fix PPA build)

[Olaf Meeuwissen]

Hi Johannes,

Johannes Meixner writes:

> Hello,
>
> On May 12 19:18 allan noahwrote (excerpt):
>
>> They are already 1.0.26+gitxxxx,
>
> Simply put:
> A version number like 1.0.26+gitxxxx should have never
> been used for somethig after 1.0.25 but before 1.0.26
> because 1.0.26+gitxxxx means that it is after 1.0.26.
> I.e. 1.0.26+gitxxxx is wrong, cf. my explanation below
> about Ghostscript release candidates where the
> Ghostscript upstream release candidate version number
> is also just wrong like 9.15rc1 for the first release
> candidate of the upcoming Ghostscript 9.15 release.

Various project use various conventions.  For distributors this sucks
because it is well nigh impossible to come up with a version comparison
algorithm that works for all the software they want to package.

The case of 1.0.26+gitxxxx was not of the SANE project's making although
we surely gave the wrong impression with our 1.0.26git.

> On May 13 12:10 Olaf Meeuwissen wrote (excerpt):
>> Distributions can also work around with an "epoch",
>> so you get something like "1:1.0.26+gitxxxx",
>> but that's a bit ugly.
>
> at least not at openSUSE because here RPM "epoch" stuff
> is "forbidden by policy".
> I don't know the exact reasons behind but at last one reason
> is - as far as I know - that once you have set an "epoch"
> yon could never ever get rid of it later.
> I.e. basically introducing "epoch" is like introducing
> a leading "absolute maximum" part of the version i.e. a switch
> from "major.minor.patchlevel" to "epoch.major.minor.patchlevel".

Correct.  There's no way you can get rid of an epoch.  It's a last
resort.  It should be avoided as much as possible.

>> But we could also just admit that we've more or less
>> goofed up on the versioning for our master branch,
>> skip 1.0.26 and release as 1.0.27.
>> Doing so will bypass any of the scenarios you worry about.
>
> Yes, please skip 1.0.26 and release as 1.0.27.
> This is simple, fail safe, and avoids needless complications.

Thanks for agreeing with me.  Let's try to keep our versioning sane, pun
intended, so distributors don't have to resort to all kinds of exotic
trickery to make upgrades work.

Hope this helps,
--
Olaf Meeuwissen, LPIC-2            FSF Associate Member since 2004-01-27
 GnuPG key: F84A2DD9/B3C0 2F47 EA19 64F4 9F13  F43E B8A4 A88A F84A 2DD9
 Support Free Software                        https://my.fsf.org/donate
 Join the Free Software Foundation              https://my.fsf.org/join