Commit | Line | Data |
---|---|---|
c38e0c97 PE |
1 | Instructions to create pretest or release tarballs. -*- coding: utf-8 -*- |
2 | -- originally written by Gerd Moellmann, amended by Francesco Potortì | |
383c1c75 | 3 | with the initial help of Eli Zaretskii |
90073820 | 4 | |
90073820 | 5 | |
31045a5b GM |
6 | Steps to take before starting on the first pretest in any release sequence: |
7 | ||
8 | 1. Decide on versions of automake and autoconf, and ensure you will | |
7d2707f9 GM |
9 | have them available for the duration of the release process. |
10 | ||
31045a5b GM |
11 | 2. Consider increasing the value of the variable |
12 | `customize-changed-options-previous-release' in cus-edit.el to | |
13 | refer to a newer version of Emacs. (This is probably needed only | |
14 | when preparing the first pretest for a major Emacs release.) | |
15 | Commit cus-edit.el if changed. | |
16 | ||
17 | ||
18 | General steps (for each step, check for possible errors): | |
19 | ||
1a71dc49 | 20 | 1. `bzr update' (for a bound branch), or `bzr pull'. |
31045a5b | 21 | bzr status # check for locally modified files |
90073820 FP |
22 | |
23 | 2. Bootstrap to make 100% sure all elc files are up-to-date, and to | |
24 | make sure that the later tagged version will bootstrap, should it be | |
25 | necessary to check it out. | |
26 | ||
7d2707f9 | 27 | 3. Regenerate the etc/AUTHORS file: |
31045a5b GM |
28 | M-: (require 'authors) RET |
29 | M-x authors RET | |
30 | ||
31 | There is almost guaranteed to be an "*Authors Errors*" buffer with | |
32 | problems caused by certain bad ChangeLog entries. You can ignore | |
33 | the very old ones (eg lisp/erc has a lot). If there are errors | |
34 | related to new entries (especially entries that are new since the | |
35 | last pretest), see if you can fix them. If there was a ChangeLog | |
36 | typo, fix it. If a file was deleted or renamed, consider adding | |
37 | an appropriate entry to authors-ignored-files, authors-valid-file-names, | |
38 | or authors-renamed-files-alist. | |
39 | ||
40 | If necessary, repeat M-x authors after making those changes. | |
41 | Save the "*Authors*" buffer as etc/AUTHORS. | |
42 | Check the diff looks reasonable. Maybe add entries to | |
43 | authors-ambiguous-files or authors-aliases, and repeat. | |
44 | Commit any fixes to ChangeLogs or authors.el. | |
c0982072 LK |
45 | |
46 | 4. Set the version number (M-x load-file RET admin/admin.el RET, then | |
7d2707f9 | 47 | M-x set-version RET). For a release, add released ChangeLog |
90073820 FP |
48 | entries (M-x add-release-logs RET). |
49 | ||
3baeb95e GM |
50 | For a pretest, start at version .90. After .99, use .990 (so that |
51 | it sorts). | |
52 | ||
9e4a1ee0 GM |
53 | The final pretest should be a release candidate. Set the version |
54 | number to that of the actual release. Pick a date about a week | |
55 | from now when you intend to make the release. Use M-x add-release-logs | |
56 | to add the ChangeLog entries for that date to the tar file (but | |
57 | not yet to the repository). Name the tar file as | |
6b88120b | 58 | emacs-XX.Y-rc1.tar. If all goes well in the following week, you |
9e4a1ee0 GM |
59 | can simply rename the file and use it for the actual release. |
60 | ||
501390c5 | 61 | 5. autoreconf -i -I m4 --force |
54aa48fe | 62 | make bootstrap |
90073820 | 63 | |
31045a5b GM |
64 | 6. Copy lisp/loaddefs.el to lisp/ldefs-boot.el. |
65 | ||
66 | Commit etc/AUTHORS, lisp/ldefs-boot.el, and the files changed | |
67 | by M-x set-version. | |
1a71dc49 | 68 | For a release, also commit the ChangeLog files in all directories. |
90073820 | 69 | |
31045a5b GM |
70 | 7. ./make-dist --snapshot --no-compress |
71 | ||
72 | Check the contents of the new tar with | |
54aa48fe | 73 | admin/diff-tar-files against an older tar file. Some old pretest |
1a71dc49 GM |
74 | tarballs may be found at <ftp://alpha.gnu.org/gnu/emacs/pretest>; |
75 | old release tarballs are at <ftp://ftp.gnu.org/pub/gnu/emacs/>. | |
90073820 | 76 | |
c789f32c GM |
77 | If this is the first pretest of a major release, just comparing |
78 | with the previous release may overlook many new files. You can try | |
1a71dc49 GM |
79 | something like `find . | sort' in a clean bzr tree, and compare the |
80 | results against the new tar contents. | |
c789f32c | 81 | |
31045a5b GM |
82 | 8. tar -xf emacs-NEW.tar; cd emacs-NEW |
83 | ./configure --prefix=/tmp/emacs && make && make install | |
7d5c9c1b FP |
84 | Use `script' or M-x compile to save the compilation log in |
85 | compile-NEW.log and compare it against an old one. The easiest way | |
86 | to do that is to visit the old log in Emacs, change the version | |
87 | number of the old Emacs to __, do the same with the new log and do | |
fe5b74fc GM |
88 | M-x ediff. Especially check that Info files aren't built, and that |
89 | no autotools (autoconf etc) run. | |
7d5c9c1b | 90 | |
31045a5b | 91 | 9. cd EMACS_ROOT_DIR && bzr tag TAG |
1e1bbf41 | 92 | TAG is emacs-XX.Y.ZZ for a pretest, emacs-XX.Y for a release. |
7d5c9c1b | 93 | |
ab22a8a1 CY |
94 | Shortly before the release, cut the version branch also, and open |
95 | a Savannah support request asking for commits to the new branch to | |
96 | be sent to the emacs-diffs mailing list (by default, the list | |
97 | normally only gets commits to the trunk). | |
e8ccb869 | 98 | |
31045a5b GM |
99 | 10. Decide what compression schemes to offer. |
100 | For a release, at least gz and xz: | |
101 | gzip --best -c emacs-NEW.tar > emacs-NEW.tar.gz | |
102 | xz -c emacs-NEW.tar > emacs-NEW.tar.xz | |
103 | ||
104 | Now you should upload the files to the GNU ftp server. In order to | |
140281f6 | 105 | do that, you must be registered as an Emacs maintainer and have your |
a0b4e66e GM |
106 | GPG key acknowledged by the ftp people. For instructions, see |
107 | http://www.gnu.org/prep/maintain/html_node/Automated-Upload-Registration.html | |
31045a5b GM |
108 | The simplest method is to use the gnulib <http://www.gnu.org/s/gnulib/> |
109 | script "build-aux/gnupload" to upload each FILE, like this: | |
110 | ||
111 | For a pretest: | |
112 | gnupload [--user your@gpg.key.email] --to alpha.gnu.org:emacs/pretest \ | |
113 | FILE.gz FILE.xz ... | |
114 | ||
115 | For a release: | |
116 | gnupload [--user your@gpg.key.email] --to ftp.gnu.org:emacs \ | |
117 | FILE.gz FILE.xz ... | |
118 | ||
119 | You only need the --user part if you have multiple GPG keys and do | |
120 | not want to use the default. | |
121 | Obviously, if you do not have a fast uplink, be prepared for the | |
122 | upload to take a while. | |
123 | ||
124 | ||
125 | If you prefer to do it yourself rather than use gnupload: | |
126 | ||
127 | For each FILE, create a detached GPG binary signature and a | |
128 | clearsigned directive file like this: | |
ab22a8a1 | 129 | |
140281f6 FP |
130 | gpg -b FILE |
131 | echo directory: emacs/pretest > FILE.directive (for a pretest) | |
132 | echo directory: emacs > FILE.directive (for a release) | |
133 | gpg --clearsign FILE.directive | |
7dee3a04 RF |
134 | Upload by anonymous ftp to ftp://ftp-upload.gnu.org/ the files FILE, |
135 | FILE.sig, FILE.directive.asc. | |
136 | For a release, place the files in the /incoming/ftp directory. | |
137 | For a pretest, place the files in /incoming/alpha instead, so that | |
138 | they appear on ftp://alpha.gnu.org/. | |
140281f6 | 139 | |
7d2707f9 | 140 | 11. After five minutes, verify that the files are visible at |
31045a5b | 141 | ftp://alpha.gnu.org/gnu/emacs/pretest/ for a pretest, or |
41a3c7b0 FP |
142 | ftp://ftp.gnu.org/gnu/emacs/ for a release. |
143 | ||
31045a5b GM |
144 | Download them and check the signatures. Check they build. |
145 | ||
7d2707f9 GM |
146 | 12. For a pretest, announce it on emacs-devel and info-gnu-emacs@gnu.org. |
147 | For a release, also announce it on info-gnu@gnu.org. (Probably | |
148 | bcc the info- addresses to make it less likely that people will | |
149 | followup on those lists.) | |
50b2d54c | 150 | |
7d2707f9 | 151 | 13. For a release, update the Emacs homepage in the web repository. |
50b2d54c | 152 | Also add the new NEWS file as NEWS.xx.y. |
31045a5b | 153 | Maybe regenerate the html manuals, update the FAQ, etc, etc. |