1 #+TITLE: Release Process for GNU Guile 2.0
2 #+AUTHOR: Ludovic Courtès
5 This document describes the typical release process for Guile 2.0.
7 * Preparing & uploading the tarball
11 … or http://bugs.gnu.org/guile, for an idea of things to fix.
15 The commit log's first line should be "Update Gnulib to X", where X is
16 the output of `git describe' in the Gnulib repo.
18 This allows us to keep track of the source code we use, in case a bug or
19 security vulnerability gets fixed in Gnulib sometime later.
21 Ideally update Gnulib several days prior to the release, so that
22 portability or build issues can be uncovered in time.
24 ** Make sure it works, portably, and with different configurations
26 *** Check [[http://hydra.nixos.org/jobset/gnu/guile-2-0][Hydra]]
28 This contains builds and cross-builds on different platforms, with
29 different `configure' switches, different CPPFLAGS, and different
30 versions of the compiler.
32 As of this writing, there are unfixed failures. For instance Darwin's
33 compiler randomly crashes, preventing build completion; the FreeBSD 7.x
34 box experiences Guile crashes while running the test suite, which were
35 not fixed because not reproduced elsewhere. Even for these platforms,
36 make sure "things don't get worse", at least.
38 *** Check [[http://autobuild.josefsson.org/guile/][Autobuild]]
40 This contains build reports from other people, typically on lesser used
41 platforms, so it's worth checking.
43 *** Use the [[http://gcc.gnu.org/wiki/CompileFarm][GCC Compile Farm]]
45 Use the GCC Compile Farm to check on lesser used architectures or
46 operating systems. In particular, the Farm has ARM, SPARC64, PowerPC,
47 and MIPS GNU/Linux boxes (remember that this is not superfluous: Debian
48 builds on 11 architectures). It also has FreeBSD and NetBSD boxes.
52 If you're still in a good mood, you may also want to check on porter
53 boxes for other OSes. The GNU/Hurd people have [[http://www.gnu.org/software/hurd/public_hurd_boxen.html][porter boxes]], so does
54 the [[http://www.opencsw.org/standards/build_farm][OpenCSW Solaris Team]].
57 *** Post a pre-release announcement to `platform-testers@gnu.org'
59 Send a link to [[http://hydra.nixos.org/job/gnu/guile-2-0/tarball/latest/download-by-type/file/source-dist][the latest tarball]]. This will allow readers to test on
60 possibly weird platforms and report any bugs.
62 ** Update `GUILE-VERSION'
64 For stable releases, make sure to update the SONAME appropriately. To
65 that end, review the commit logs for libguile in search of any C ABI
66 changes (new functions added, existing functions deprecated, etc.)
67 Change `LIBGUILE_INTERFACE_*' accordingly. Re-read the Libtool manual
70 `libguile/libguile.map' should also be updated as new public symbols are
71 added. Ideally, new symbols should get under a new version
72 symbol---e.g., `GUILE_2.0.3' for symbols introduced in Guile 2.0.3.
73 However, this has not been done for Guile <= 2.0.2.
77 Create a signed Git tag, like this:
79 $ git tag -s u MY-KEY -m "GNU Guile 2.0.X." v2.0.X
81 The tag *must* be `v2.0.X'. For the sake of consistency, always use
82 "GNU Guile 2.0.X." as the tag comment.
84 ** Push the tag and changes
86 $ git push && git push --tags
88 Normally nobody committed in the meantime. ;-)
92 This should trigger an `autoreconf', as `build-aux/git-version-gen'
93 notices the new tag. After "make dist", double-check that `./configure
94 --version' reports the new version number.
96 The reason for running "make dist" instead of "make distcheck" is that
97 it's much faster and any distribution issues should have been caught by
102 $ ./build-aux/gnupload --to ftp.gnu.org:guile guile-2.0.X.tar.gz
104 You'll get an email soon after when the upload is complete.
106 Your GPG public key must be registered for this to work (info
107 "(maintain) Automated Upload Registration").
109 Make sure to publish your public key on public OpenPGP servers
110 (keys.gnupg.net, pgp.mit.edu, etc.), so that people can actually use it
111 to check the authenticity and integrity of the tarball.
115 Make sure the file was uploaded and is available for download as
118 $ mkdir t && cd t && wget ftp.gnu.org/gnu/guile/guile-2.0.X.tar.gz
119 $ diff guile-2.0.X.tar.gz ../guile-2.0.X.tar.gz
125 First, re-read the GNU Maintainers Guide on this topic (info "(maintain)
130 - Replace any references to the previous version number and replace it
134 ** Update the on-line copy of the manual
136 - Use `build-aux/gendocs', add to the manual/ directory of the web
139 ** Prepare the email announcement
141 $ build-aux/announce-gen --release-type=stable --package-name=guile \
142 --previous-version=2.0.1 --current-version=2.0.2 \
143 --gpg-key-id=MY-KEY --url-directory=ftp://ftp.gnu.org/gnu/guile \
144 --bootstrap-tools=autoconf,automake,libtool,gnulib \
145 --gnulib-version=$( cd ~/src/gnulib ; git describe )
147 The subject must be "GNU Guile 2.0.X released". The text should remain
148 formal and impersonal (it is sent on behalf of the Guile and GNU
149 projects.) It must include a description of what Guile is (not everyone
150 reading info-gnu may know about it.) Use the text of previous
151 announcements as a template.
153 Below the initial boilerplate that describes Guile should come the
154 output of `announce-gen', and then the `NEWS' file excerpt in its
155 entirety (don't call it a change log since that's not what it is.)
157 ** Send the email announcement
159 - guile-user@gnu.org, guile-devel@gnu.org, guile-sources@gnu.org
160 - info-gnu@gnu.org (for stable releases only!)
163 ** Post a news on [[http://sv.gnu.org/p/guile/][Savannah]]
165 The news will end up on planet.gnu.org. The text can be shorter and
166 more informal, with a link to the email announcement for details.
170 Copyright © 2011 Free Software Foundation, Inc.
172 Copying and distribution of this file, with or without modification,
173 are permitted in any medium without royalty provided the copyright
174 notice and this notice are preserved.