sane-project-backends/doc/releases.txt

48 wiersze
1.7 KiB
Plaintext

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