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 -- sane-devel mailing list: [email protected] http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/sane-devel Unsubscribe: Send mail with subject "unsubscribe your_password" to [email protected]
