[sane-devel] Sane Release 1.1.0 ?

[Olaf Meeuwissen]

"m. allan noah" <kitno455 at gmail.com> writes:

> On Wed, Nov 5, 2008 at 6:44 PM, Olaf Meeuwissen
> <olaf.meeuwissen at avasys.jp> wrote:
>> "m. allan noah" <kitno455 at gmail.com> writes:
>>
>>> On Wed, Nov 5, 2008 at 8:42 AM, Julien BLACHE <jb at jblache.org> wrote:
>>>> "m. allan noah" <kitno455 at gmail.com> wrote:
>>>>
>>>>> Sanity is not the problem. The extreme need to make a release, coupled
>>>>> with limited developer resources is the problem. Lets bump the version
>>>>> everywhere to 2.
>>>>
>>>> Sanity and consistency of the API and its behaviour is the problem.
>>>
>>> we are making only modest changes to the API. It's behaviour is MORE
>>> consistent with the current code than with your suggestion.
>>>
>>>> And I just can't believe you're pushing a release because "we need to
>>>> release" and breaking things along the way.
>>>
>>> This is YOUR opinion. I think adding additional statuses to
>>> SANE_Status is perfect, and protecting them with version bump follows
>>> the standard to the letter.
>>
>> Julien is not the only one with that opinion.  I for one don't care
>> for a release that was pushed out of the door for the benefit of a
>> mere three backends that want/need the additions and in the mean time
>> break things along the way for all frontends and external backends.
>>
>>  - what other reasons are there to release in such a rush?
>
> a rush? it will be 9 months since last release if we were to start the
> process today, and i never suggested that. i never even gave a
> timeline.

OK, I'll rephrase that question then:

  - what other reasons are there that lead to an "extreme need to make
    a release"?

>>  - how do you support mixed (API/so)version installations?
>>   - will a version 2 dll backend still load version 1 backends?
>
> It should be able to, since old backends are forward compatible

If you bump the soversion someone will need to fix the dll backend or
otherwise it won't.

>>   - can version 2 frontends use version 1 backends?
>
> unless the dll backend is going to change the version number, they
> will have to, because of external backends.

Are you talking about the dll backend advertising version 1 backends
as version 2 backends to the frontends here?

Also note that the SANE API specification explicitly mentions the
possibility of switching backends.  Please don't make the mistake of
assuming everyone everywhere will be using the dll backend as their
frontend's backend of choice.  Not saying you do, just pointing out
the possibility.

>>   - will version 1 frontends do the right thing with all version 2
>>     backends?
>
> no, that is why there is a soversion bump. we HAVE to have some
> mechanism to make incompatible changes to the API.

ACK on the soversion bump but keep in mind that you need to support
setups with *both* soversion 1 and soversion 2 backends installed.

You suggested changing the version number to 2 everywhere.  That would
include the sane-backends and sane-frontends package versions and the
SANE Standard version (and SANE_CURRENT_MAJOR).  I hope I didn't miss
any versions anywhere.  As Julien already pointed out, changing the
Standard version for the changes we have now is a really bad joke.  If
we can't even do something as simple as adding a SANE_Status value
without a major standard version increase, something's gotta be wrong
with the way we handle versioning.

>>   - can everyone find the right match of versions?
>
> most folks use the free backends we ship, and they will all be version
> 2.

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.

> External backends that stay at v1 should still work. there is
> nothing in the standard that precludes a frontend from supporting two
> versions, or the dll backend could change the version as it passes by,
> and still be accurate, since a v1 backend works just like a v2
> backend, but does not use the new statuses or frame types.

A soversion 2 dll backend could bump the SANE_CURRENT_MAJOR of
soversion 1 backends on the fly (assuming the dll backend actually
loads them) but that seems to make the whole point of
SANE_CURRENT_MAJOR a bit meaningless ...

> I am open to suggestions on all these points. That is why I am pushing
> the issue, to get some ideas, and some help.

I'd like to help but resources are scarce.  CVS is also a show stopper
(corporate firewall is getting in the way, SVN would work).

Hope this helps,
-- 
Olaf Meeuwissen, LPIC-2           FLOSS Engineer -- AVASYS Corporation
FSF Associate Member #1962               Help support software freedom
                 http://www.fsf.org/jf?referrer=1962