Some Notes About Release ======================== Index - Names - Platforms - Indications - Requirements - Checklist - Notifications Names ----- Maybe we should name Guile releases after entertaining poisons: absinthe, etc. However, the first release containing the module system should be called Godot: "This is the one you've been waiting for." Platforms --------- For test builds: SunOS (gcc and pcc) --- galapas.ai.mit.edu Solaris (gcc and SUN cc) --- saturn.ai.mit.edu NetBSD (gcc) --- repo-man.ai.mit.edu (use /home/repo/jimb) HP/UX (gcc, HP cc) --- nutrimat.gnu.ai.mit.edu These gentlemen have kindly offered to do pre-release testing: Tom Tromey : alphaev5-unknown-linux-gnu hppa1.1-hp-hpux10.20 hppa1.1-hp-hpux11.00 mips-sgi-irix5.3 powerpc-ibm-aix4.2.0.0 powerpc-unknown-linux-gnu sparc-sun-solaris2.6 i686-pc-linux-gnu mips-sgi-irix6.3 sparc-sun-sunos4.1.4 Perry Metzger NetBSD Indications [fixme:rlb] ----------- A release can be for whim, but it's better if there are some pre-conditions that "indicate" the release (like certain symptoms indicate using medication). Typical indications are: * new feature freeze * documentation sync'ed * various scripts are happy * change moderated by release manager * discussion required for non-bugfix changes * all RC bugs fixed Requirements [fixme:rlb] ------------ * some kind of say about what does and doesn't go into the stable branch * ... Release Checklist ----------------- There are basically three phases to doing a release: * "BRANCHING": Creating a stable development branch in CVS. * "SPIFFING": Updating NEWS, README, INSTALL. Running tests. Getting people to try builds on various machines. Getting everything straightened up. * "PUNTING": Updating the version numbers. Tagging the sources. Asking the FSF to put the disty on ftp.gnu.org. Posting announcements. The "Spiffing" phase you might go through several times as you discover problems. The "Branching" and "Punting" phases you do only once. Branching checklist: * Announce when you're about to make the branch so that you have a greater chance of people holding off on edits during the short period while you're branching. * Make sure you're on the main trunk (see HACKING), and then create the branch-root tag. i.e. -r branch-root_release-1-6. (Add the exact command here next time I do it.) * Now create the branch with the branch tag. i.e. -r branch_release-1-6. (Add exact command here next time I do it.) * Change the version numbers in GUILE-VERSION and README on the main branch to reflect the new unstable version i.e. 1.7.0, if you're currently creating the 1.6.X branch. Spiffing checklist: NOTE: Unless you're *SURE* you know what you're doing, please perform the following actions in order. The ordering is important in places below. * Make sure you're working on the stable branch (see HACKING for details). Note that after following the branch checklist above, you won't necessarily be. * Make sure you've got the latest files "cvs -qz3 update -Pd". * Check for files that have changed a lot, but do not have up-to-date copyright notices. This can be as simple as doing: grep 'Copyright' * | grep -v 1999 and looking for files you know you've worked on a lot. * Make sure NEWS, INSTALL, AUTHORS and THANKS and the docs are up to date: + Scan the ChangeLogs for user-visible changes, marked with an asterisk at the left margin. + Update NEWS and the Texinfo documentation as appropriate. + Remove the user-visible markers from the log entries once they're documented. + Check for any [[incomplete]] sections of NEWS. + Fact-check INSTALL. + Make sure AUTHORS and THANKS are up-to-date (see also TODO). + Remove finished items from TODO (those marked w/ "+"). * Make sure the downloading addresses and filenames in README are current. (But don't bump the version number yet. We do that below.) * Check that the versions of aclocal, automake, autoconf, and autoheader in your PATH match those given in HACKING. Note that the `make dist' process always invokes these tools, even when all the generated files are up to date. Make specifically sure that the files in libltdl are generated using the same tools as the rest. * Build the test distribution NOTE: during this section, don't commit any of your changes to CVS until the instructions tell you to below. This is important so that someone doesn't check out CVS and think that they have a finished copy of a particular release when they actually don't. * update GUILE-VERSION to reflect the current test distribution, but don't commit this change to CVS yet (see below). For example, just before the 1.6.0 release, we went through some number of 1.5.X test releases. * Run ./autogen.sh to rebuild all generated files in the source tree. * configure the source tree for build in the same tree with these configuration options: --enable-maintainer-mode --enable-debug-malloc --with-threads --enable-error-on-warning --prefix=/wherever/you/want * Build the tree. (If the above two steps are not done first, the dependencies won't be properly included in the generated Makefile.in files.) * Run "make" and "make check". * Run "make dist". * test the resultant tarfile yourself using the instructions under "Testing a release candidate tarfile" below. * Add a "Guile beta N.M released." entry to the top-level ChangeLog. * Now commit all your changes to CVS. * Tag the release "cvs tag release_1-5-2". * Run 'make dist' again to get the official tarfile. * Give the test disty to various people to try. They should follow the same instructions under "Testing a release candidate tarfile" below. * Testing a release candidate tarfile: * Unset GUILE_LOAD_PATH. * Remove automake and autoconf from your path, or turn off their execute bits, or something. (Users must be able to build from the tarfile without installing those tools.) As an example, you could disable the tools during the test like so: mkdir /tmp/stub cat > /tmp/stub/do-nothing <