mirror/guile
mirror/guile
1
Fork 0
mirror of https://git.savannah.gnu.org/git/guile.git synced 2025-05-14 17:50:22 +02:00
Code Activity

bye bye

Browse source
This commit is contained in:
Thien-Thi Nguyen 2002-04-03 10:25:11 +00:00
parent 7e9af3f9cd
commit 99f17158af
1 changed files with 0 additions and 177 deletions
Download patch file Download diff file Expand all files Collapse all files

177
RELEASE
View file

@ -1,177 +0,0 @@
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."
In release 1.5:
- remove deprecated macros: SCM_INPORTP, SCM_OUTPORTP, SCM_CRDY, SCM_ICHRP,
SCM_ICHR, SCM_MAKICHR, SCM_SETJMPBUF, SCM_NSTRINGP, SCM_NRWSTRINGP,
SCM_NVECTORP
- remove gc-thunk (It has been replaced by after-gc-hook.)
- remove scm_sysmissing
- remove gh_int2scmb (replaced by gh_bool2scm)
- remove scm_fseek (replaced by scm_seek)
- remove scm_tag
- remove code related to the name property of hooks. Also, check init.c,
since the dependency between hooks and objprop will then be eliminated.
- remove deprecated function scm_list_star/list* (use SRFI-1 compliant
scm_cons_star/cons* instead.)
- remove scm_tc16_flo, scm_tc_flo (guile always uses doubles to represent
inexact real numbers)
- remove scm_tc_dblr (replaced by scm_tc16_real)
- remove scm_tc_dblc (replaced by scm_tc16_complex)
- remove deprecated types, functions and macros from numbers.h: scm_dblproc,
SCM_UNEGFIXABLE, SCM_FLOBUFLEN, SCM_INEXP, SCM_CPLXP, SCM_REAL, SCM_IMAG,
SCM_REALPART, scm_makdbl, SCM_SINGP, SCM_NUM2DBL, SCM_NO_BIGDIG
Modules sort.c and random.c should be factored out into separate
modules (but still be distributed with guile-core) when we get a new
module system.
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
Ian Grant <I.A.N.Grant@damtp.cam.ac.uk>:
alpha-dec-osf4.0e
Julian Satchell <satchell@merry.dra.hmg.gb>:
dec-mips-ultrix
Perry Metzger <perry@piermont.com>
NetBSD
Release Checklists ===================================================
There are basically two phases to doing a release:
* "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 "Punting" phase you do only once.
Spiffing checklist:
* Do a `cvs update -A', to get rid of any sticky tags in your working
directory.
* 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 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 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.
* Rebuild all generated files in the source tree:
+ Install the .m4 files where aclocal will find them.
+ Run aclocal.
+ Run autoconf.
+ Run autoheader.
+ Run automake.
* Verify that Guile builds and runs in your working directory.
* Run the test suite, in guile-core/test-suite.
* Commit all changes to the CVS repository.
* Build a test distribution.
+ BEFORE doing 'make dist', configure the source tree for build
in the same tree with configuration options
--enable-maintainer-mode --enable-debug-malloc --with-threads.
+ Make sure that readline was enabled correctly.
+ Build the tree.
(If the above steps are not done, the dependencies won't be properly
included in the generated Makefile.in files.)
+ Then do 'make dist'.
+ 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.)
* Give the test disty to various people to try. Here's what you should do:
+ 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 the
disty without installing those tools.)
+ Configure, make, and install.
+ Make sure LD_LIBRARY_PATH doesn't include anything unnecessary.
+ Run the test suite on the installed version.
+ You might try the example code in the doc directory.
Once you've got a disty that seems pretty solid:
* Choose new interface numbers for shared libraries.
* Update the version numbers in GUILE-VERSION and README. (There are
many places in README that need updating!) The Guile version
number should have one of the following forms:
N.M - a major release
N.M.L, where L is even - a minor release
N.M.L, where L is odd - sources from CVS or nightly snapshot
* Reformat the names in THANKS.
* Do a `cvs update -A' 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 N.M released." entry to the top-level ChangeLog, and commit it.
* Tag the entire source tree with a tag of the form "release_N_M"
or "release_N_M_L".
* 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.
* Tweak the version numbers in GUILE-VERSION, and README to indicate
that the sources are a snapshot again. Snapshots should have
version numbers of the form "N.M.L", where L is odd.
* Start a new section of the NEWS file.
* Start a new THANKS file.
* Send mail to majordomo-owner@cygnus.com updating the message you
get when you ask majordomo for "info guile".