On Mon, 2008-10-13 at 13:55 -0400, m. allan noah wrote:
> On Mon, Oct 13, 2008 at 11:45 AM, Ren? Rebe <rene at exactcode.de> wrote:
> > Hi,
> >
> > Julien BLACHE wrote:
> >> stef <stef.dev at free.fr> wrote:
> >>
> >> Hi,
> pseudocode:
>
> ret = sane_start()
> if(ret){
> die("bad status");
> }
>
> that works in sane 1.0, and fails in sane 1.1, both with the original
> binary, and with a new binary compiled against 1.1 headers. Thus, it
> is both a source and a binary incompatibility, which calls for a
> soversion bump. We knew this going in, yet some folks were very much
> against the bump, so we split hairs, and tried to say it was not big
> enough to matter. That was a foolish choice, which drove some
> developers away. I take a great measure of personal responsibility for
> that.
>
> We have several choices as i see it:
>
> 1. Remove new status values and release sane 1.1. (do we need to
> remove other things?)
>
> 2. Release this as sane 2.0.
>
> 3. Reopen the sane 2.0 discussion, and make more drastic changes to the API.
>
Is there not a option 4:
4. Leave sane_start as it is now with the same returncodes as it has in
sane-1.0, and add a sane_start2 that has the new returncode(s) in
addition to the old one?
I have not looked at the code myself, but would assume that this is
quite doable. Frontends that are modified will use the new interface
with the new returncodes, non-modified frontends will use the old
interface but will continue to work....
br, Louis
