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"
