"m. allan noah" <kitno455 at gmail.com> writes: > On Tue, Oct 14, 2008 at 6:31 AM, Julien BLACHE <jb at jblache.org> wrote: >> Olaf Meeuwissen <olaf.meeuwissen at avasys.jp> wrote: >> >> Hi, >> >>>> 2. Release this as sane 2.0. >>> >>> If there were few other changes besides those for the 1.1 stuff, a >>> soversion bump is probably the best way to move forward. However, >>> considering the scope of the changes, 2.0 feels a little like an >>> overstatement and we could consider some extra, non-controversial!, >>> API-breaking changes. Are there any ;-) >> >> Also note that the soname bears no relation to the SANE standard >> version, and should not. >> >> SANE standard version can be part of the library name, ie >> libsane-2.so.1 would be SANE 2.0.
ACK. I am aware of the distinction but forgot about it when replying yesterday :-( > while this is technically true, i personally find it kind of annoying. > A library like sane effectively IS its interface, so changing the > interface is changing the version number. ACK here as well. A libsane.so.2 for SANE 1.1 and libsane2.so.1 for SANE 2.0 may be somewhat confusing but it's probably the only decent thing to do. So if we bump the soversion for SANE 1.1, then all 1.1 backends need to do so as well and an 1.1 dll backend needs to be made to look for .so.2 backends. IIRC, it already looks for .so.# files, but the # is the SANE MAJOR version. [Me goes and checks] Yup, it appends V_MAJOR and just about every backend (epkowa included) confuses that with the SANE Standard defined SANE_CURRENT_MAJOR when it creates a SANE_VERSION_CODE. Only the snapscan backend does the right thing here. There is an interesting little snippet in ChangeLog-1.0.1 on February 27, 1999: * backend/snapscan.c (EXPECTED_MAJOR): Update EXPECTED_MAJOR to 1. * include/sane/sane.h (SANE_CURRENT_MAJOR): SANE_CURRENT_MAJOR and V_MAJOR HAVE to be in sync, so I'm forced to fix SANE_CURRENT_MAJOR now. Embarassing, but fortunately only the snapscan backend seems affected by this change. * backend/dll.c (load): Use SANE_CURRENT_MAJOR, not V_MAJOR (the latter is used for shared lib versioning). It looks there a fair bit of version number unconfusing to be done before we can ship 1.1. There's the SANE Standard, library version information (soversion, etc) and the sane-* package versions. Up till now, these happened to be pretty much the same, numerically, but they have always been independent in terms of meaning. The numerical similarity seems to have confused their use for the last 10 years or so. FWIW, the libtool Versioning section[1] may be an interesting read. [1] http://www.gnu.org/software/libtool/manual/libtool.html#Versioning Hope this helps, -- Olaf Meeuwissen, LPIC-2 FLOSS Engineer -- AVASYS Corporation FSF Associate Member #1962 Help support software freedom http://www.fsf.org/jf?referrer=1962
