| 1 | Instructions to create pretest or release tarballs. -*- coding: utf-8 -*- |
| 2 | -- originally written by Gerd Moellmann, amended by Francesco Potortì |
| 3 | with the initial help of Eli Zaretskii |
| 4 | |
| 5 | |
| 6 | Steps to take before starting on the first pretest in any release sequence: |
| 7 | |
| 8 | 0. The release branch (e.g. emacs-24) should already have been made |
| 9 | and you should use it for all that follows. Diffs from this |
| 10 | branch should be going to the emacs-diffs mailing list (see |
| 11 | admin/notes/bzr section on bzr-email plugin). |
| 12 | |
| 13 | 1. Decide on versions of automake and autoconf, and ensure you will |
| 14 | have them available for the duration of the release process. |
| 15 | |
| 16 | 2. Consider increasing the value of the variable |
| 17 | `customize-changed-options-previous-release' in cus-edit.el to |
| 18 | refer to a newer version of Emacs. (This is probably needed only |
| 19 | when preparing the first pretest for a major Emacs release.) |
| 20 | Commit cus-edit.el if changed. |
| 21 | |
| 22 | 3. Remove any old pretests from ftp://alpha.gnu.org/gnu/emacs/pretest. |
| 23 | You can use `gnupload --delete' (see below for more gnupload details). |
| 24 | |
| 25 | General steps (for each step, check for possible errors): |
| 26 | |
| 27 | 1. `bzr update' (for a bound branch), or `bzr pull'. |
| 28 | bzr status # check for locally modified files |
| 29 | |
| 30 | 2. Regenerate the etc/AUTHORS file: |
| 31 | M-: (require 'authors) RET |
| 32 | M-x authors RET |
| 33 | |
| 34 | If there is an "*Authors Errors*" buffer, address the issues. |
| 35 | If there was a ChangeLog typo, fix it. If a file was deleted or |
| 36 | renamed, consider adding an appropriate entry to authors-ignored-files, |
| 37 | authors-valid-file-names, or authors-renamed-files-alist. |
| 38 | |
| 39 | If necessary, repeat M-x authors after making those changes. |
| 40 | Save the "*Authors*" buffer as etc/AUTHORS. |
| 41 | Check the diff looks reasonable. Maybe add entries to |
| 42 | authors-ambiguous-files or authors-aliases, and repeat. |
| 43 | Commit any fixes to ChangeLogs or authors.el. |
| 44 | |
| 45 | 3. Set the version number (M-x load-file RET admin/admin.el RET, then |
| 46 | M-x set-version RET). For a release, add released ChangeLog |
| 47 | entries (M-x add-release-logs RET). |
| 48 | |
| 49 | For a pretest, start at version .90. After .99, use .990 (so that |
| 50 | it sorts). |
| 51 | |
| 52 | The final pretest should be a release candidate. Set the version |
| 53 | number to that of the actual release. Pick a date about a week |
| 54 | from now when you intend to make the release. Use M-x add-release-logs |
| 55 | to add the ChangeLog entries for that date to the tar file (but |
| 56 | not yet to the repository). Name the tar file as |
| 57 | emacs-XX.Y-rc1.tar. If all goes well in the following week, you |
| 58 | can simply rename the file and use it for the actual release. |
| 59 | |
| 60 | 4. autoreconf -i -I m4 --force |
| 61 | make bootstrap |
| 62 | |
| 63 | make -C etc/refcards |
| 64 | make -C etc/refcards clean |
| 65 | |
| 66 | 5. Copy lisp/loaddefs.el to lisp/ldefs-boot.el. |
| 67 | |
| 68 | Commit etc/AUTHORS, lisp/ldefs-boot.el, and the files changed |
| 69 | by M-x set-version. Use a commit log message that bzrmerge.el |
| 70 | will ignore (eg "Bump version..."). |
| 71 | For a release, also commit the ChangeLog files in all directories. |
| 72 | |
| 73 | If someone else made a commit between step 1 and now, |
| 74 | you need to repeat from step 4 onwards. (You can commit the files |
| 75 | from step 2 and 3 earlier to reduce the chance of this.) |
| 76 | |
| 77 | 6. ./make-dist --snapshot --no-compress |
| 78 | |
| 79 | Check the contents of the new tar with admin/diff-tar-files |
| 80 | against the previous release (if this is the first pretest) or the |
| 81 | previous pretest. If you did not make the previous pretest |
| 82 | yourself, find it at <ftp://alpha.gnu.org/gnu/emacs/pretest>. |
| 83 | Releases are of course at <ftp://ftp.gnu.org/pub/gnu/emacs/>. |
| 84 | |
| 85 | If this is the first pretest of a major release, just comparing |
| 86 | with the previous release may overlook many new files. You can try |
| 87 | something like `find . | sort' in a clean bzr tree, and compare the |
| 88 | results against the new tar contents. |
| 89 | |
| 90 | 7. tar -xf emacs-NEW.tar; cd emacs-NEW |
| 91 | ./configure --prefix=/tmp/emacs && make && make install |
| 92 | Use `script' or M-x compile to save the compilation log in |
| 93 | compile-NEW.log and compare it against an old one. The easiest way |
| 94 | to do that is to visit the old log in Emacs, change the version |
| 95 | number of the old Emacs to __, do the same with the new log and do |
| 96 | M-x ediff. Especially check that Info files aren't built, and that |
| 97 | no autotools (autoconf etc) run. |
| 98 | |
| 99 | 8. cd EMACS_ROOT_DIR && bzr tag TAG |
| 100 | TAG is emacs-XX.Y.ZZ for a pretest, emacs-XX.Y for a release. |
| 101 | |
| 102 | 9. Decide what compression schemes to offer. |
| 103 | For a release, at least gz and xz: |
| 104 | gzip --best -c emacs-NEW.tar > emacs-NEW.tar.gz |
| 105 | xz -c emacs-NEW.tar > emacs-NEW.tar.xz |
| 106 | For pretests, just xz is probably fine (saves bandwidth). |
| 107 | |
| 108 | Now you should upload the files to the GNU ftp server. In order to |
| 109 | do that, you must be registered as an Emacs maintainer and have your |
| 110 | GPG key acknowledged by the ftp people. For instructions, see |
| 111 | http://www.gnu.org/prep/maintain/html_node/Automated-Upload-Registration.html |
| 112 | The simplest method to upload is to use the gnulib |
| 113 | <http://www.gnu.org/s/gnulib/> script "build-aux/gnupload": |
| 114 | |
| 115 | For a pretest: |
| 116 | gnupload [--user your@gpg.key.email] --to alpha.gnu.org:emacs/pretest \ |
| 117 | FILE.gz FILE.xz ... |
| 118 | |
| 119 | For a release: |
| 120 | gnupload [--user your@gpg.key.email] --to ftp.gnu.org:emacs \ |
| 121 | FILE.gz FILE.xz ... |
| 122 | |
| 123 | You only need the --user part if you have multiple GPG keys and do |
| 124 | not want to use the default. |
| 125 | Obviously, if you do not have a fast uplink, be prepared for the |
| 126 | upload to take a while. |
| 127 | |
| 128 | |
| 129 | If you prefer to do it yourself rather than use gnupload: |
| 130 | |
| 131 | For each FILE, create a detached GPG binary signature and a |
| 132 | clearsigned directive file like this: |
| 133 | |
| 134 | gpg -b FILE |
| 135 | echo directory: emacs/pretest > FILE.directive (for a pretest) |
| 136 | echo directory: emacs > FILE.directive (for a release) |
| 137 | gpg --clearsign FILE.directive |
| 138 | Upload by anonymous ftp to ftp://ftp-upload.gnu.org/ the files FILE, |
| 139 | FILE.sig, FILE.directive.asc. |
| 140 | For a release, place the files in the /incoming/ftp directory. |
| 141 | For a pretest, place the files in /incoming/alpha instead, so that |
| 142 | they appear on ftp://alpha.gnu.org/. |
| 143 | |
| 144 | 10. After five minutes, verify that the files are visible at |
| 145 | ftp://alpha.gnu.org/gnu/emacs/pretest/ for a pretest, or |
| 146 | ftp://ftp.gnu.org/gnu/emacs/ for a release. |
| 147 | |
| 148 | Download them and check the signatures. Check they build. |
| 149 | |
| 150 | 11. Send an announcement to: emacs-devel, and bcc: info-gnu-emacs@gnu.org. |
| 151 | For a pretest, also bcc: platform-testers@gnu.org. |
| 152 | (The reason for using bcc: is to make it less likely that people |
| 153 | will followup on the wrong list.) |
| 154 | See the info-gnu-emacs mailing list archives for the form |
| 155 | of past announcements. The first pretest announcement, and the |
| 156 | release announcement, should have more detail. |
| 157 | |
| 158 | 12. For a release, update the Emacs homepage in the web repository. |
| 159 | Also update history.html, and add the new NEWS file as NEWS.xx.y. |
| 160 | Regenerate the html manuals (use make-manuals from admin.el). |
| 161 | If there are new manuals, add appropriate index pages. |