[sane-devel] SANE frozen in amber ?

[Kåre Särs]

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