[sane-devel] Sane Release 1.1.0 ?
jb at jblache.org
Thu Nov 6 17:13:11 UTC 2008
"m. allan noah" <kitno455 at gmail.com> wrote:
> My biggest concerns are those raised by Olaf- how do the two versions
> coexist. I will bet you that the solution we come up with will be
> EXACTLY the same, whether we add your new function or not. So, i want
No, if we go and add an optional status function, this problem does
not exist. I covered that in my mail.
If we go that route and do a 1.1, the dll backend can load *.so.1* and
be done with it. If it's a 1.1 backend, it will have the function
defined, nothing more to do, if it's a 1.0 backend it won't have it
and dll wires up a stub instead. All backends in 1.1 define the
function, a stub is used for all the backends that are unmaintained
There, done, no problem. Total backward compatibility with anything
built against 1.0. No change in the behaviour of the current API
calls. Some work to do on saned/net as the new call needs to added and
the version check needs to be extended a bit (1.1 client cannot talk
to a 1.0 saned or needs to wire up a stub call for the new call). No
big issue, takes time and testing.
Plus: new status function frontends can use at any time (though the
function can reply "sorry can't tell you now"), and in 2.0 we can
separate API status (SANE_Retval or something) and hardware status
(SANE_Status or something else).
Now, speaking of a proper 2.0 release, this has all been discussed
already. I think the best thing we came up with was a sane1 compat
backend based on dll that does the conversion and stuff. That and
installing the backends under /usr/lib/sane2 (avoids dupes - note that
you can restrict dll to *.so.2* and sane1 to *.so.1* instead). Some
work on saned/net required as usual, version check needs some work and
testing to ensure saned and the client reject the other version as
Makes no sense for such small changes.
Julien BLACHE <http://www.jblache.org>
<jb at jblache.org> GPG KeyID 0xF5D65169
More information about the sane-devel