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