mirror of
https://git.savannah.gnu.org/git/guile.git
synced 2025-05-04 14:20:26 +02:00
bye bye
This commit is contained in:
Thien-Thi Nguyen
parent
647c008adc
commit
f422cac2b0
1 changed files with 0 additions and 250 deletions
250
RELEASE
250
RELEASE
|
|
@ -1,250 +0,0 @@
|
|||
-*-text-*-
|
||||
This is a checklist for making Guile releases.
|
||||
It's specific to the FSF's development environment; please don't put
|
||||
it in the distribution.
|
||||
|
||||
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 <tromey@cygnus.com>:
|
||||
|
||||
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 <perry@piermont.com>
|
||||
|
||||
NetBSD
|
||||
|
||||
|
||||
Release Checklists ===================================================
|
||||
|
||||
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 <<EOF
|
||||
#!/bin/sh
|
||||
echo warning: $0 called
|
||||
sleep 10
|
||||
exit 0
|
||||
EOF
|
||||
chmod +x /tmp/stub/do-nothing
|
||||
ln /tmp/stub/do-nothing /tmp/stub/automake
|
||||
ln /tmp/stub/do-nothing /tmp/stub/autoconf # etc
|
||||
PATH=/tmp/stub:$PATH
|
||||
|
||||
* Configure, "make", "make check", and "make install". Make sure to
|
||||
remove your previous install tree before the "make install".
|
||||
|
||||
* Make sure LD_LIBRARY_PATH doesn't include anything unnecessary.
|
||||
|
||||
* Run the test suite on the installed version.
|
||||
./check-guile -i [INSTALL_PATH]/bin/guile
|
||||
|
||||
* Look at the install tree (with "find | sort" or similar) and make
|
||||
sure nothing seems obviously amiss.
|
||||
|
||||
* Check that the dependencies in guile-readline/Makefile look OK.
|
||||
(We currently use a kludge which edits the dependencies generated
|
||||
by automake so that Guile can be built in a directory separate
|
||||
from the source tree also with non-GNU make programs.)
|
||||
|
||||
* Make sure readline works.
|
||||
|
||||
* You might try the example code in the doc directory.
|
||||
|
||||
Once you've got a disty that seems pretty solid:
|
||||
|
||||
* Make sure the shared library libtool versioning numbers are correct,
|
||||
but first make sure you understand "Libtool's versioning system" in
|
||||
the libtool info pages. Guile is going to be versioning it's shared
|
||||
libraries independently, so follow the libtool rules for choosing
|
||||
version numbers, but make sure to keep in mind that not everyone is
|
||||
as good about this as they should be. In any case, note that if
|
||||
your library passes through data structures that were produced by
|
||||
some sub-library, and that sub-libraries data has changed
|
||||
in a publically incompatible way, then this may mean that *your*
|
||||
library's API has changed in a publically incompatible way.
|
||||
|
||||
* In general, there will be a number of libraries in guile that will
|
||||
have to be versioned, and it would be best if the people who know
|
||||
the most about the individual libs decide what the apropriate
|
||||
CURRENT, REVISION, and AGE numbers for each one are. In general,
|
||||
though, you have to be conservative. If no one is sure that the
|
||||
libs are still compatible, then you *must* make the appropriate
|
||||
changes under the assumption that they're not. Getting this wrong
|
||||
is very BAD(TM).
|
||||
|
||||
* Make the final update to the version numbers in GUILE-VERSION and
|
||||
README. (There are many places in README that need updating!). See
|
||||
HACKING for more information on how the version numbers are to be
|
||||
chosen.
|
||||
|
||||
* Reformat the names in THANKS.
|
||||
|
||||
* Do a `cvs -z3 update -Pd' of the whole tree, to look for any stray
|
||||
uncommitted or accidental changes.
|
||||
|
||||
* Commit your changes.
|
||||
|
||||
* Make one last test distribution.
|
||||
|
||||
Punting checklist:
|
||||
|
||||
* Add "Guile X.Y.Z released." entry to the top-level ChangeLog, and commit it.
|
||||
|
||||
* Tag the entire source tree with a tag of the form "release_X-Y-Z",
|
||||
i.e for release 1.6.1, use release_1-6-1
|
||||
|
||||
* Do a 'make dist'.
|
||||
|
||||
* Put the distribution up for FTP somewhere, and send mail to
|
||||
ftp-upload@gnu.org, asking them to put it on prep.
|
||||
|
||||
* Send an announcement message to gnu-announce@gnu.org. Put a brief
|
||||
summary of the changes in this release first, then "Obtaining
|
||||
Guile", "Thanks", "About This Distribution," and "Nightly
|
||||
Snapshots." If I remember correctly, the moderator will delay it
|
||||
until the distribution appears on ftp.gnu.org. The announcement
|
||||
text should be mostly taken from Guile's README file.
|
||||
|
||||
* Notify freshmeat.net, although they're probably watching anyway.
|
||||
(They got the 1.3 release just fine.) I have no idea if
|
||||
www.bowerbird.com.au will be something anyone refers to, but Guile
|
||||
does have an entry there.
|
||||
Loading…
Add table
Add a link
Reference in a new issue