[sane-devel] SANE2 standard revisited

[Henning Meier-Geinitz]

Hi,

On Mon, Dec 09, 2002 at 12:21:56PM -0500, Matto Marjanovic wrote:
> There is already a "microtek2.conf", because there are microtek and microtek2
>  backends.

Ok, so /etc/sane2.d/... .

> Could there be conflicts between old/new files in .../include/sane, too ?

I don't think so. The only files that get installed are sane.h and
saneopts.h and these will be named appropriately. All the local files
must be updated, there won't be an SANE1/SANE2 mix iin the SANE
distribution.

> If the directories were renamed to "sane2" for SANEv2, then one could have
>  coexisting SANEv1 and SANEv2 installations, which might be a good thing.
>  Or not.  (If so, frontends/metabackends/etc could look in the SANEv1
>  directory for old backends...)

That's the plan, yes. Well, it's my plan, I don't know how the others
think. I guess we need some sort of compatibility layer as some old
backends won't be ported (hopefully!) to SANE2.

>  >Currently we have lot's of different version numbers. SANE standard,
>  >sane-distribution, and backends. I hope we can merge the last two.
>  >
>  >So why don't we use only two numbers for SANE releases like 2.0, 2.1,
>  >2.23? We haven't needed the second number until now and I see no
>  >reason for it. So the distribution would use e.g. 2.4 and a backend
>  >that is included would use 2.4.something with something is the backend
>  >build or version number. So you immediately know which SANE version
>  >was used.
> 
> Fine with me:  (STANDARDS-VERSION).(RELEASE-NUMBER)

Oliver raised some valid objections that the SANE release may in
future have numbers like 2.4.7 because the standard may evolve more
than currently without breaking compatibility.

> If the standard itself had a minor number (used for incremental, backwards-
>  -compatible changes/improvements/clarifications), then I would say that
>  should end up in there.  But it doesn't.  (Right?)

We have a minor standard number (printed on the front) that is
increased with every significant change. The current number is 1.03.
But this minor number isn't found in the SANE version code. And I
don't think it need to be found. If it's compatible, no need to use
it. If it isn't compatible, increase the major version number.

> (I never quite understood the version number thing --- microtek.c always
>  just tracked the SANE release (using V_MAJOR/V_MINOR), and had its own
>  internal version code for debugging purposes.)

Basically you can print whatever version number you want. But for
consitency, we should only use one number in the backend.
So the backend should use the minor + build numbers however it likes
but it should really set them They can be e.g. printed by the dll
debug messages.

Bye,
  Henning