On Friday 12 June 2009 20:52:57 m. allan noah wrote: > On Fri, Jun 12, 2009 at 12:45 PM, Richard > > Ryniker<ryniker at ryniker.ods.org> wrote: > >> a frontend that asks for new, unsupported features, will simply > >> get an appropriate error code. > > > > Allen Noah, earlier in this thread (Thu Jun 11 19:08:28 UTC 2009) alluded > > > > to the problem with this approach when he wrote: > >>bah- then no front-end will use it, since it is not guaranteed to be > >>there. > > <snip> > > > I believe SANE, like many other applications, will find it better to > > change its API in infrequent, discrete steps than to follow a "continuous > > change is permitted" strategy. > > Well, you can't get much more infrequent API changes than SANE :) > > Seriously, we have to bump the major number on the soversion to do any > changes. The only real question is what do we do with all the > unmaintained backends?
If I may comment on this as a frontend developer. For me a major number bump would be welcome, if I get new features. > > 1: drag them along via modification I have understood that it is hard to get enough manpower as it is, so this does not sound viable at the moment. > 2: leave them behind and make the frontends link against sane1 and sane2 This does not sound fun for a frontend developer :) > 3: leave them behind and use a sane-compat meta-backend to make them > appear to have the sane2 api This is the alternative I would vote for. > 4: make our API modifications small enough that old backends will be > forward compatible Sooner or later there _is_ going to be a need to break the compatibility to get new features. > > Note that all 4 of these options are easier for the programmer if the > API changes are kept small. Are there any other choices? > K?re
