[sane-devel] Fix PPA build

[Olaf Meeuwissen]

Hi all,

This is something that I've been wondering about for a while and with
the release coming up I thought I'd vent my thoughts/preferences on the
version numbering of sane-backends (and sane-frontends if we should ever
get around to releasing a new version of that).

Rolf Bensch writes:

> Hi James,
>
> Am 08.05.2017 um 22:22 schrieb James Duvall:
>> Rolf,
>>
>> Thanks for getting your ppa back up and running.  However, I am not able
>> to install the libsane package using apt, even when I try to force the
>> version.  I believe that your new version numbering with ~ is causing
>> the problem.
>>
>> ver=1.0.26~ppa20170508-yakkety0; sudo apt-get install libsane=$ver
>> libsane-common=$versane-utils=$ver

On Debian-based distributions:

  1.0.26~this < 1.0.26 < 1.0.26+that

I don't recall the details for RPM-based distributions re ~ (note that
Fedora[1] says it should not be used), but the + works the same, so:

  1.0.26 < 1.0.26+that

  [1] https://fedoraproject.org/wiki/Packaging:Versioning

The problem with the way we currently do the versioning of sane-backends
is that we bump the version to what we *think* will be the next version.
This would work for Debian-based distribution packages if they use a ~
suffix to our version.  For RPM-based distributions I don't know what
works.  It also causes confusing bug reports and mails to the list where
people talk about using an upcoming release.

To fix that, can we agree to a version number for HEAD on master that
refers to the last *released* version?  Something like this

  1.0.26+git

for anything *after* the 1.0.26 release.  This should work for all folks
rolling binary packages and indicates very clearly that it's 1.0.26 plus
a bunch of edits.

Actually, we may also want to look into using the output of

  git describe

When I run this on my current checkout of master, I get

  RELEASE_1_0_25-552-ge6711c3

This is <tag>-<number-of-commits-since-tag>-g<commit-ish>, so this
should work fine as long as people are using master.  The number of
commits since the tag will sort later commits in the right order.

# We haven't used branches much so far, so this would be a reasonably
# safe assumption.  Anyway, if you're using any other branch, I would
# assume you know what you're doing ;-)

If we also switch tags to use the version number as is, that would
become

  1.0.25-552-ge6711c3

# Debian-based distributions may need to replace the - with something
# else.  Using `sed 's/-/+/g'` or something similar should work.

Summarizing, let's use

  <last-*released*-version>+git

from the 1.0.26 release onwards and look into using the output from `git
describe` to get an even better idea of what people are really running
when compiling from git.

How's that sound?

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