[sane-devel] Sane Release 1.1.0 ?

[Olaf Meeuwissen]

stef <stef.dev at free.fr> writes:

> Le Wednesday 29 October 2008 19:59:09 Julien BLACHE, vous avez écrit :
>> Nicolas Martin <nicolas.martin at freesurf.fr> wrote:
>>
> ...
>>
>> Also calling the current CVS SANE 2.0 is really a bad joke given
>> there's only very little changes compared to SANE 1.0. I don't think
>> it's warranted and I don't think it's a good thing.
>>
>> JB.
>>
>> --
>> Julien BLACHE                                   <http://www.jblache.org>
>> <jb at jblache.org>                                  GPG KeyID 0xF5D65169
>
> 	Hello,
>
> 	there are only 2 changes in the SANE API:
> 	- new SANE_FRAME values 
> 	- new SANE_STATUS
>
> 	Whenever a frontend built against SANE 1.0 receive one of the new status, it 
> shows the error properly. Like SANE_STATUS_COVER_OPEN, JAMMED or NO_DOCS, in 
> case of SANE_STATUS_WARMING_UP user has to correct the error condition (in 
> this case just by waiting) before starting a new scan. When the error 
> condition is fixed (scanner is warm enough), the scan goes normally.
>
> 	For the new frame formats (tested with a hacked pnm backend), when XSane 
> receives a format it doesn't know, there is a 'Bad frame format 11' pop-up. 
> Kooka doesn't send any error, and user gets a black scan .
>
> 	So the current picture of using a SANE 1.0 frontend against a SANE 'next 
> version' is that there may be some errors in the case the user requires an 
> frame format that isn't known for the frontend. Currently only the bh, 
> coolscan3 and fujitsu backends take advantage of the new SANE_FRAME values.

Any frontend using the dll backend will be affected, in principle.

> 	If you think -as a package maintainer- these errors are important enough to 
> require a V_MAJOR increase, we'll have to call next SANE version SANE 2.0 due 
> to the way the standard worked (only the major is taken into account), and 
> the way backends misused V_MAJOR instead of SANE_CURRENT_MAJOR. 

For all I know, all backends but one still misuse V_MAJOR.

Personally, I am of the opinion that we should clean up the version
mess first and come up with a workable and backwardly compatible
versioning scheme.  Any such scheme should allow for simultaneous
installation of multiple (major) versions.

> 	I am comfortable with releasing the current CVS as SANE 2.0 even the amount 
> of API change is minimal since is has a technical merit. Keeping the current 
> work as SANE 1.1 doesn't disturb either since the errors would be limited, 
> but I'm not the one that will have to cope with the bug reports.
>
> 	But i definitely want a conclusion to be taken regarding how to call next 
> version 2.0 or 1.1.

What version are you talking about here?

I agree with Julien that bumping the API specification version to 2.0
is a bad joke.  Bumping the soversion of those backends that actually
support/use the additions to 2 is the Right Thing to do, however.

# Note that the current dll backend implementation does NOT support a
# mixed soversion scenario.

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