Hello, On Nov 13 22:11 stef wrote: > in order to demonstrate the possibility to have SANE 1 and SANE 2 > coexisting by using meta backends, here's a demo patch against > recent CVS which: > - raise V_MAJOR to 2 > - add a sane1 meta backend that loads backends with a so major of 1 to > allow SANE 2 frontends to use SANE 1 backends > - add a sane2 meta backend with a so major of 1 but searches for backends > with a so major of 2. It also handles the warming up status, and detects > use of newer frame formats. So a SANE 1 frontend would be able to use a > SANE 2 backend. > > So even after an installation of SANE 2 packages: > - SANE 1 only backends such as binary one can still be used > - SANE 1 frontends can use SANE 2 backends > This let package maintainers to upgrade at their will and/or > when frontends get updated to take advantage of new features. > Custom or binary frontends won't need to be updated.
Regarding the names of the compatibility meta backends: I wonder if your naming scheme is future-proof so that it would also work to have SANE 1, SANE 2, SANE 3,... coexisting? I assume that in a short time after SANE 2 new features require SANE 3, SANE 4,... I think it is perfectly o.k. to just raise the major version number if there is a incompatibility so that development can just move forward without the need to have a never-ending discussion to make the next version "the last final solution forever". But then there must be a future-proof method how to keep backward compatibility. Therefore I suggest to have a more verbose naming scheme for the compatibility meta backends with two numbers: - one is its own version number (i.e. the version number which match to the frontend which links with this compatibility meta backend) - the other one is the compatibility version number (i.e. the version number which match to the backend which is linked by this compatibility meta backend) So that - a sane2_1 compatibility meta backend loads backends with a so major of 1 to allow SANE 2 frontends to use SANE 1 backends - a sane1_2 compatibility meta backend loads backends with a so major of 2 to allow SANE 1 frontends to use SANE 2 backends And for the future - a sane3_1 compatibility meta backend loads backends with a so major of 1 to allow SANE 3 frontends to use SANE 1 backends - a sane3_2 compatibility meta backend loads backends with a so major of 2 to allow SANE 3 frontends to use SANE 2 backends - a sane1_3 compatibility meta backend loads backends with a so major of 3 to allow SANE 1 frontends to use SANE 3 backends - a sane2_3 compatibility meta backend loads backends with a so major of 2 to allow SANE 2 frontends to use SANE 3 backends By the way: What about saned and the net meta backend? Are compatibility saneds and compatibility net meta backends also needed, e.g. when on the server SANE 1 runs but on the client already SANE 2 (servers are usually not as often upgraded than client workstations) and/or vice versa? Kind Regards Johannes Meixner -- SUSE LINUX Products GmbH, Maxfeldstrasse 5, 90409 Nuernberg, Germany AG Nuernberg, HRB 16746, GF: Markus Rex
