[sane-devel] question about next SANE release

[m. allan noah]

On Tue, Nov 25, 2008 at 12:43 AM, stef <stef.dev at free.fr> wrote:
>        Hello,
>
>        there have been a few inconclusive threads on the next release of SANE. I'd
> really wish that a decision could be taken so we can make a release in not a
> distant future.
>
>        If the current CVS is released as SANE 1.1, what would be the extent of the
> changes ?
>        - only the rts8891 backend uses the new SANE_STATUS_WARMING_UP.
>        - only the canon_dr, fujitsu, coolscan3 and bh backends uses the new frame
>          formats
>         In the case someone installs the latest release without any care, there will
> be no damages, and only -in some cases- the rts8891 backend could not be
> used. In even rarer circumstances, if a new frame format is required, the scan
> will fail. That's not that much.
>        Furthermore, someone working properly would read the release notes and be
> informed of the changes. By shipping a compatibility meta backend, we will be
> able to allow the safe use of the updated backends with not yet updated
> frontends. Once SANE  is released, the frontends coders will take notice and
> will update at their own pace. There is already code in scanimage and
> xscanimage which handles the new features that can be use as an example.
>        Due to the way the changes have been made in SANE, any existing backend (be
> it out of tree or binary only) will still work as expected without being
> touch at all.
>        So I really think we should carry on the initial plan, and release it as SANE
> 1.1 . It brings needed new features with very limited impact on frontends,
> and no impact at all on external backends.

I agree that the changes are minor, but they _ARE_ an API/ABI change.
The sane standard is our 'contract' with front-end developers, and it
is very clear. Any backends which support the changed API must return
'2' for the major number of their versions.  dll.c and net.c will
require particular attention, since they also mix in a third, private
version number. You could still call this sane 1.1., though I
personally think it is clearer for frontend devels and easier to
maintain if you call it sane 2 everywhere.

Now, to make this possible, I have just committed a patch which uses
SANE_CURRENT_MAJOR instead of V_MAJOR everywhere that seemed
reasonable. dll and net still need some work. If we can fix those, it
should be possible to bump the protocol version independently of the
package version.

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