[sane-devel] The future of the SANE-Standard

m. allan noah kitno455 at gmail.com
Fri Dec 21 22:10:23 UTC 2007


On Dec 21, 2007 4:55 PM, Julien BLACHE <jb at jblache.org> wrote:
> Oliver Rauch <Oliver.Rauch at rauch-domain.de> wrote:
>
> Hi,
>
> > My hope is that someone who knows what he does gets active and
> > directs this disaster into the right way... or stopps all this.
>
> Nothing has been committed to CVS yet, no code has even been written,
> and 1.0.19 will go first. So there's still a comfortable margin.
>
> That said, bumping the soname is going to be a big deal and I'm not in
> favor of doing that unless there's a good reason to do so.
>
> The frame types addition can be done without changing the API. Adding
> new functions to the API can be done without bumping the soname (only
> a minor version increment, major stays at 1, so soname remains
> libsane.so.1).
>
>
> Anything else, you'd better have a GOOD reason for changing the API
> (or ABI, be careful) and bumping the soname. Because it's sure going
> to be a mess. If it's for convergence to SANE2, then sure, go for
> it. But not now.
>
>
> Bottom line: bumping the soname is not warranted for the frame types
> addition. Going to 1.1.x is enough.
>

the problem that oliver is pointing out is this:

4.1 Version Control
The SANE standard is expected to evolve over time. Whenever a change
to the SANE standard is made that may render an existing frontend or
backend incompatible with the new standard, the major version number
must be increased. Thus, any frontend/backend pair is compatible
provided the major version number of the SANE standard they implement
is the same.

Boy, this is getting hairy, because it requires you to define
'incompatible'. i daresay that we would each define it a bit
differently in this case.

allan

-- 
"The truth is an offense, but not a sin"



More information about the sane-devel mailing list