[sane-devel] Fix PPA build

[m. allan noah]

this sounds like a reasonable plan to me, though I wonder what effect
it will have on the currently installed git-based packages. They are
already 1.0.26+gitxxxx, and they will remain so after this release
(though the xxxx part will be of a different format).

allan

On Thu, May 11, 2017 at 7:36 AM, Olaf Meeuwissen
<paddy-hack at member.fsf.org> wrote:
> 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



-- 
"well, I stand up next to a mountain- and I chop it down with the edge
of my hand"