RELEASE

   1 This is a checklist for making Guile releases.
   2 It's specific to the FSF's development environment; please don't put
   3 it in the distribution.
   4
   5 Maybe we should name Guile releases after entertaining poisons:
   6 absinthe, etc.  However, the first release containing the module
   7 system should be called Godot: "This is the one you've been waiting
   8 for."
   9
  10 Platforms for test builds:
  11 SunOS (gcc and pcc) --- galapas.ai.mit.edu
  12 Solaris (gcc and SUN cc) --- saturn.ai.mit.edu
  13 NetBSD (gcc) --- repo-man.ai.mit.edu (use /home/repo/jimb)
  14 HP/UX (gcc, HP cc) --- nutrimat.gnu.ai.mit.edu
  15
  16 These gentlemen have kindly offered to do pre-release testing:
  17
  18 Tom Tromey <tromey@cygnus.com>:
  19
  20   alphaev5-unknown-linux-gnu
  21   hppa1.1-hp-hpux10.20
  22   hppa1.1-hp-hpux11.00
  23   mips-sgi-irix5.3
  24   powerpc-ibm-aix4.2.0.0
  25   powerpc-unknown-linux-gnu
  26   sparc-sun-solaris2.6
  27   i686-pc-linux-gnu
  28   mips-sgi-irix6.3
  29   sparc-sun-sunos4.1.4
  30
  31 Ian Grant <I.A.N.Grant@damtp.cam.ac.uk>:
  32
  33   alpha-dec-osf4.0e
  34
  35 Julian Satchell <satchell@merry.dra.hmg.gb>:
  36
  37   dec-mips-ultrix
  38
  39 Perry Metzger <perry@piermont.com>
  40
  41   NetBSD
  42
  43
  44 Release Checklists ===================================================
  45
  46 There are basically two phases to doing a release:
  47
  48 * "SPIFFING": Updating NEWS, README, INSTALL.  Running tests.  Getting
  49   people to try builds on various machines.  Getting everything
  50   straightened up.
  51
  52 * "PUNTING": Updating the version numbers.  Tagging the sources.  Asking
  53   the FSF to put the disty on ftp.gnu.org.  Posting announcements.
  54
  55 The "Spiffing" phase you might go through several times as you
  56 discover problems.  The "Punting" phase you do only once.
  57
  58
  59 Spiffing checklist (NOTE: these instructions are out of date now that
  60 we're using cvs branches for stable vs unstable).
  61
  62 * Do a `cvs update -A', to get rid of any sticky tags in your working
  63   directory.
  64 * Check for files that have changed a lot, but do not have up-to-date
  65   copyright notices.  This can be as simple as doing:
  66         grep 'Copyright' * | grep -v 1999
  67   and looking for files you know you've worked on a lot.
  68 * Make sure NEWS, INSTALL, AUTHORS and THANKS and the docs are up to date:
  69   + Scan the ChangeLogs for user-visible changes, marked with an asterisk
  70     at the left margin.
  71   + Update NEWS and the Texinfo documentation as appropriate.
  72   + Remove the user-visible markers from the log entries once they're
  73     documented.
  74   + Check for any [[incomplete]] sections of NEWS.
  75   + Fact-check INSTALL.
  76   + Make sure AUTHORS and THANKS are up-to-date (see also TODO).
  77   + Remove finished items from TODO (those marked w/ "+").
  78 * Make sure the downloading addresses and filenames in README are
  79   current.  (But don't bump the version number yet.  We do that below.)
  80 * Check that the versions of aclocal, automake, autoconf, and autoheader
  81   in your PATH match those given in HACKING.  Note that the `make
  82   dist' process always invokes these tools, even when all the
  83   generated files are up to date.
  84   Make specifically sure that the files in libltdl are generated using
  85   the same tools as the rest.
  86 * Rebuild all generated files in the source tree:
  87   + Install the .m4 files where aclocal will find them.
  88   + Run aclocal.
  89   + Run autoconf.
  90   + Run autoheader.
  91   + Run automake.
  92 * Verify that Guile builds and runs in your working directory.
  93 * Run the test suite, in guile-core/test-suite.
  94 * Commit all changes to the CVS repository.
  95 * Build a test distribution.
  96   + BEFORE doing 'make dist', configure the source tree for build
  97     in the same tree with configuration options
  98     --enable-maintainer-mode --enable-debug-malloc --with-threads.
  99   + Make sure that readline was enabled correctly.
 100   + Build the tree.
 101     (If the above steps are not done, the dependencies won't be properly
 102     included in the generated Makefile.in files.)
 103   + Then do 'make dist'.
 104   + Check that the dependencies in guile-readline/Makefile look OK.
 105     (We currently use a kludge which edits the dependencies generated
 106     by automake so that Guile can be built in a directory separate
 107     from the source tree also with non-GNU make programs.)
 108 * Give the test disty to various people to try.  Here's what you should do:
 109   + Unset GUILE_LOAD_PATH.
 110   + Remove automake and autoconf from your path, or turn off their
 111     execute bits, or something.  (Users must be able to build the
 112     disty without installing those tools.)
 113   + Configure, make, and install.
 114   + Make sure LD_LIBRARY_PATH doesn't include anything unnecessary.
 115   + Run the test suite on the installed version.
 116   + You might try the example code in the doc directory.
 117
 118 Once you've got a disty that seems pretty solid:
 119
 120 * Choose new interface numbers for shared libraries.
 121 * Update the version numbers in GUILE-VERSION and README.  (There are
 122   many places in README that need updating!)  The Guile version
 123   number should have one of the following forms:
 124     N.M                      - a major release
 125     N.M.L, where L is even   - a minor release
 126     N.M.L, where L is odd    - sources from CVS or nightly snapshot
 127 * Reformat the names in THANKS.
 128 * Do a `cvs update -A' of the whole tree, to look for any stray
 129   uncommitted or accidental changes.
 130 * Commit your changes.
 131 * Make one last test distribution.
 132
 133 Punting checklist:
 134
 135 * Add "Guile N.M released." entry to the top-level ChangeLog, and commit it.
 136 * Tag the entire source tree with a tag of the form "release_N_M"
 137   or "release_N_M_L".
 138 * Do a 'make dist'.
 139 * Put the distribution up for FTP somewhere, and send mail to
 140   ftp-upload@gnu.org, asking them to put it on prep.
 141 * Send an announcement message to gnu-announce@gnu.org.  Put a brief
 142   summary of the changes in this release first, then "Obtaining
 143   Guile", "Thanks", "About This Distribution," and "Nightly
 144   Snapshots."  If I remember correctly, the moderator will delay it
 145   until the distribution appears on ftp.gnu.org.  The announcement
 146   text should be mostly taken from Guile's README file.
 147 * Notify freshmeat.net, although they're probably watching anyway.
 148   (They got the 1.3 release just fine.)  I have no idea if
 149   www.bowerbird.com.au will be something anyone refers to, but Guile
 150   does have an entry there.
 151 * Tweak the version numbers in GUILE-VERSION, and README to indicate
 152   that the sources are a snapshot again.  Snapshots should have
 153   version numbers of the form "N.M.L", where L is odd.
 154 * Start a new section of the NEWS file.
 155 * Start a new THANKS file.