2003-09-24

This text summarizes some points to pay attention to when a new release
of sane-backends should is planned.

Timetable (approximate periods):

Day  0: Announcement of upcoming release on sane-devel including timetable
Day 14: Backend freeze (no new backends are allowed to enter the distribution)
Day 21: Feature freeze (only bugfixes + documentation updates)
Day 35: Code freeze (only fixes for bugs that can destroy hardware, can cause 
        compilation problems or render a backend completely unusable, and
        documentation updates are allowed)
Day 42: Release

Before the release:

* Make sure that config.guess and config.sub are up-to-date (get them from
  ftp://ftp.gnu.org/pub/gnu/config/).
* configure.in: increase version number (twice!)
* configure.in: remove -cvs from textual version number
* configure.in: set is_release=no
* configure: recreate
* NEWS: update and enter date of release
* sane-backends.lsm: update
* ChangeLog: set release marker
* final compilation test
* tag CVS with release tag; e.g.: 'cvs tag RELEASE_1_0_4'
* make diff from last release;
  e.g.: 'cvs diff -uNr RELEASE_1_0_3 > sane-1.0.4.diff'

Making the release:

* make tar.gz and sane-backends-x.y.z.lsm with "make sane-backends"
* upload both to the FTP server
* update sane-backends.html and sane-mfgs.html on sane-project.org
* update SANE standard and man pages on sane-project.org
* check and update platforms page on sane-project.org
* write announcements on sane-project.org and sane-devel, maybe others
  (e.g. freshmeat)
* upload to mirrors that don't get the files automatically (sunsite)

After the release:

* configure.in: add -cvs suffix
* configure.in: set is_release=no
* configure: regenerate