[sane-devel] Sane Release 1.1.0 ?

[m. allan noah]

On Fri, Nov 7, 2008 at 1:08 AM, Olaf Meeuwissen
<olaf.meeuwissen at avasys.jp> wrote:
> stef <stef.dev at free.fr> writes:
>
>> Le Thursday 06 November 2008 03:14:28 Olaf Meeuwissen, vous avez écrit :
>> ...
>>> They can't use these version 2 backends if they're stuck with a
>>> version 1 frontend.  Hence the need for support for a scenario where
>>> you have both version 1 and version 2 backends installed.
>>
>>       to define a way both version can coexist we have to know        what are the cases
>> which lead to this coexistence on a system. In my -possibly simplistic- view,
>> since any out of tree backend only needs a mere recompile to get in sync, I
>> don't see at first where is the problem. Could you tell me the precise cases
>> you are thinking of ?
>
> Put yourself in Julien's Debian maintainer shoes.
>
> Debian's lenny lists 15 packages that depend on libsane and 1
> (OpenOffice.org) that suggests it.  This only covers packages in main.
> These packages come from 11 different projects, 12 if you consider
> sane-frontends and sane-backends different projects, and are available
> for at least 4 different architectures.  These are all free software,
> so getting them all fixed (upstream) in time for the next release is,
> eh well, an unenviable job.  You want to volunteer?
>
> Do you also want to volunteer for all those other distributions out
> there?  Even just the major 10 or so?
>
> Next, consider what you would need to do to get an out of tree
> non-free backend in sync.  Repeat the exercise for non-free frontends.
>
> The chances that all the pieces are in place before anyone's
> particular deadline are probably less than winning the lottery.  This
> means that at any given time for the foreseeable future, people will
> have to deal with frontends and backends of both versions.
>
> Hope this paints a picture,

certainly it does- because it points out that the only connection we
have with all of those software packages is the sane standard
document. And the standard document is very clear. We are making
incompatible API/ABI changes, and we must bump the major version
number. Yes- I agree with you and Julien that the changes are fairly
minimal, but we dont have the option to bump just a minor number.

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