[sane-devel] Sane Release 1.1.0 ?

[stef]

Le Tuesday 04 November 2008 03:02:07 Olaf Meeuwissen, vous avez écrit :
> 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.

	The clean-up you are thinking of is going through all the sane_init function 
in all backends and change the version code building to use 
SANE_CURRENT_MAJOR ? 

>
> > 	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?

	SANE current CVS which has SANE 1.1 version in code.

>
> 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.

	Feature wise, it is heavy handed to call it 2.0, but it sides step issues 
with unmaintained backends that would have been to be changed. But also, 
having a current major change would allow in dll.c to choose between a 
sane1/sane2 subdir based on the major required by the frontend, providing 
esay coexistence of both versions.

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

	I agree with you, fontends that follow the SANE API (such as xsane and 
gnoescan) use only the major number to check the compatibility. libkscan 
doesn't check anything and as then no troubles.
 
>
> Hope this helps,


Regards,
	Stef