[sane-devel] sane-backends 1.0.19 Code Freeze

m. allan noah kitno455 at gmail.com
Wed Jan 23 14:38:26 UTC 2008

On Jan 23, 2008 6:14 AM, René Rebe <rene at exactcode.de> wrote:
> On 23.01.2008, at 02:47, m. allan noah wrote:
> > Note #1:
> > This will be (hopefully) the last release of the SANE 1.0 series. The
> > next release of SANE will be extended (in a backwards compatible
> > fashion) to support more features of modern scanners. Please join the
> > sane-devel mailing list to take part in the ongoing discussions of the
> > future of SANE.
> I find this alarming for two different reasons. First of all SANE
> already
> historically had a slow release cycle and it should not follow other
> projects
> into slow and ever breaking development.
> Additionally; How big can the changes be? IMHO SANE should rather
> be incrementally and compatible changed for newer features, simillar
> as POSIX standards or Linux develops. So that no fundamental
> incompatibilities are created.

apparently you mis-read what i wrote, and/or mis-remember all the
prior threads on this subject. we are specifically going to have
backwards compatibility, with SANE 1.1.0 only adding some additional
frame types, and perhaps clarifying some more well-known options. We
are doing exactly what you wish, so I do not understand your

> For me it is not the feature set of SANE would require a major over-
> haul. It would be rather nicer to changes the interna of SANE to avoid
> code bloat, such as re-implementation of calibration, gamma table
> use etc. pp. to not re-implement all this in every backend. However
> that could be archived without breaking the API for frontends or
> existing
> backends.

i agree with this idea- but it has no real bearing on our release
cycle, since sanei is not part of the public API. in fact, i have a
sanei_gamma on my hard-drive right now :)

> > Note #2:
> > The epson backend has joined our growing list of unmaintained
> > backends. As the SANE API matures in a future releases of SANE, these
> > backends could be dropped due to lack of support. If you have access
> > to scanners, documentation, or programming cycles, and are looking for
> > an interesting project, picking up one of the unmaintained backends
> > can be an easy way to get started with SANE.
> And this is exactly why Linux rocks, keeping supporting the even most
> ancient ISA, Parport, etc. devices, SPARCs, etc. and why it should be
> important to not break anything in the SANE world and instead gradually
> evolve it.

your understanding of linux kernel and mine do not jive, as i
routinely see old unmaintained hardware drivers dropped. i have
several ancient scsi and ethernet cards which have not worked since
2.0/2.2. If you want those old drivers to be forward ported to API
changes, then either we have to do it, or we have to get more
developers. I am hoping for the latter :)

but your desire to keep older hardware working does not seem to jive
with the current state of the Avison bug reports...

> I even would go as far and suggest rather release a incremental
> SANE version every few month, so that new device support, features
> go to the users in-time and developer actually get feedback quickly
> when and if some device support broke.

yes- i agree. i will gladly hand over the release coordination to you :)

> But that are just my 2€cent.

which i believe are worth quite a bit more than my 2$cents :)

"The truth is an offense, but not a sin"

More information about the sane-devel mailing list