Hi, On 23.01.2008, at 02:47, m. allan noah wrote:
> Slightly later than the timetable announced on 2007-11-16, > sane-backends is now in code freeze. After code freeze only > documentation updates and fixes of grave bugs that render a backend > completely unusable or break compilation are accepted. > > The remaining event (may move a few days if required): > 2008-02-03 Release sane-backends-1.0.19 > > New backends since SANE 1.0.18: > cardscan, epjitsu, epson2, hp3900, hp5590, hpljm1005, hs2p > > 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. 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. > 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. 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. But that are just my 2?cent. Have fun, -- Ren? Rebe - ExactCODE GmbH - Europe, Germany, Berlin http://exactcode.de | http://t2-project.org | http://rene.rebe.name
