On Mon, Oct 13, 2008 at 2:49 PM, Louis Lagendijk
<louis at lagendijk.xs4all.nl> wrote:
> 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?
binary compatibility generally works both ways- a binary that uses
sane_start2, could not be used with sane 1.0, even if rebuilt from
source.
allan
--
"The truth is an offense, but not a sin"
