2002-09-26

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

Timetable (approximate periods):

Day  0: Announcement of upcomming 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
* configure.in: remove EXTRA version number
* configure.in: set --disable-warnings as default
* 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 mostang.com
* make sane-backends.html (in doc/) and upload to mostang.com
* update SANE standard and man pages on mostang.com 
  (look at `make install-mostang' for both)
* check and update platforms page on mostang.com
* write announcements on mostang.com and sane-devel, maybe others
  (e.g. freshmeat)
* upload to mirrors that don't get the files automatically (sunsite
  and tsx11)

After the release:

* configure.in: set --enable-warnings as default
* configure.in: add EXTRA version number (usually "-cvs")
* configure: regenerate
