-Instructions to create pretest or release tarballs.
--- originally written by Gerd Moellmann, amended by Francesco Potortì
- with the initial help of Eli Zaretskii
-
-For each step, check for possible errors.
-
-1. `bzr update' (for a bound branch), or `bzr pull'.
- bzr status # check for locally modified files
-
-2. Bootstrap to make 100% sure all elc files are up-to-date, and to
- make sure that the later tagged version will bootstrap, should it be
- necessary to check it out.
-
-3. Regenerate Emacs' etc/AUTHORS file (M-x load-file RET
- lisp/emacs-lisp/authors.el RET, then M-x authors RET, then save
- the *Authors* buffer). This may require fixing syntactically
- incorrect ChangeLog entries beforehand.
-
-4. Set the version number (M-x load-file RET admin/admin.el RET, then
- M-x set-version RET). For a release, add released change log
- entries (M-x add-release-logs RET).
-
- For a pretest, start at version .90. After .99, use .990 (so that
- it sorts).
-
- If needed, increment the value of the variable
- `customize-changed-options-previous-release' in cus-edit.el to
- refer to a newer release of Emacs. (This is probably needed only
- when preparing a major Emacs release, or branching for it.)
-
-5. autoreconf -i -I m4 --force
- make bootstrap
-
-6. Commit etc/AUTHORS, all the files changed by M-x set-version, and
- lisp/cus-edit.el (if modified).
- Copy lisp/loaddefs.el to lisp/ldefs-boot.el and commit lisp/ldefs-boot.el.
- For a release, also commit the ChangeLog files in all directories.
-
-7. make-dist --snapshot. Check the contents of the new tar with
- admin/diff-tar-files against an older tar file. Some old pretest
- tarballs may be found at <ftp://alpha.gnu.org/gnu/emacs/pretest>;
- old release tarballs are at <ftp://ftp.gnu.org/pub/gnu/emacs/>.
-
- If this is the first pretest of a major release, just comparing
- with the previous release may overlook many new files. You can try
- something like `find . | sort' in a clean bzr tree, and compare the
- results against the new tar contents.
-
-8. xdelta delta emacs-OLD.tar.gz emacs-NEW.tar.gz emacs-OLD-NEW.xdelta
-
-9. tar -zxf emacs-NEW.tar.gz; cd emacs-NEW
- ./configure && make && make -n install
- Use `script' or M-x compile to save the compilation log in
- compile-NEW.log and compare it against an old one. The easiest way
- to do that is to visit the old log in Emacs, change the version
- number of the old Emacs to __, do the same with the new log and do
- M-x ediff. Especially check that Info files aren't built.
-
-10. cd EMACS_ROOT_DIR; bzr tag TAG
- TAG is emacs-XX.Y.ZZ for a pretest, emacs-XX.Y for a release.
-
- Shortly before the release, cut the version branch also, and open
- a Savannah support request asking for commits to the new branch to
- be sent to the emacs-diffs mailing list (by default, the list
- normally only gets commits to the trunk).
-
-11. Now you should upload the files to the GNU ftp server. In order to
- do that, you must be registered as an Emacs maintainer and have your
- GPG key acknowledged by the ftp people. For instructions, see
- http://www.gnu.org/prep/maintain/html_node/Automated-Upload-Registration.html
- You can use the gnupload script to upload each FILE, like this:
- gnupload --to alpha.gnu.org:emacs/pretest FILE (for a pretest)
- gnupload --to ftp.gnu.org:emacs FILE (for a release)
-
- Instead of using gnupload, for each FILE, create a detached GPG
- binary signature and a clearsigned directive file like this:
- gpg -b FILE
- echo directory: emacs/pretest > FILE.directive (for a pretest)
- echo directory: emacs > FILE.directive (for a release)
- gpg --clearsign FILE.directive
- Upload by anonymous ftp to ftp://ftp-upload.gnu.org/ the files FILE,
- FILE.sig, FILE.directive.asc.
- For a release, place the files in the /incoming/ftp directory.
- For a pretest, place the files in /incoming/alpha instead, so that
- they appear on ftp://alpha.gnu.org/.
-
- For a release, upload a bz2 tarfile as well; this can save a lot
- of bandwidth.
-
-12. After five minutes, verify that the files are visible at
- ftp://alpha.gnu.org/gnu/emacs/pretest/ for a pretest, at
- ftp://ftp.gnu.org/gnu/emacs/ for a release.
-
-13. For a pretest, announce it on emacs-devel and BCC the pretesters.
- For a release, announce it on info-gnu@gnu.org,
- info-gnu-emacs@gnu.org, and emacs-devel.
-
-14. For a release, update the Emacs homepage in the web repository.
- Also add the new NEWS file as NEWS.xx.y.
+Instructions to create pretest or release tarballs. -*- coding: utf-8 -*-
+-- originally written by Gerd Moellmann, amended by Francesco Potortì
+ with the initial help of Eli Zaretskii
+
+
+Steps to take before starting on the first pretest in any release sequence:
+
+0. The release branch (e.g. emacs-24) should already have been made
+ and you should use it for all that follows. Diffs from this
+ branch should be going to the emacs-diffs mailing list (see
+ admin/notes/bzr section on bzr-email plugin).
+
+1. Decide on versions of automake and autoconf, and ensure you will
+ have them available for the duration of the release process.
+
+2. Consider increasing the value of the variable
+ `customize-changed-options-previous-release' in cus-edit.el to
+ refer to a newer version of Emacs. (This is probably needed only
+ when preparing the first pretest for a major Emacs release.)
+ Commit cus-edit.el if changed.
+
+3. Remove any old pretests from ftp://alpha.gnu.org/gnu/emacs/pretest.
+ You can use `gnupload --delete' (see below for more gnupload details).
+
+General steps (for each step, check for possible errors):
+
+1. `bzr update' (for a bound branch), or `bzr pull'.
+ bzr status # check for locally modified files
+
+2. Regenerate the etc/AUTHORS file:
+ M-: (require 'authors) RET
+ M-x authors RET
+
+ If there is an "*Authors Errors*" buffer, address the issues.
+ If there was a ChangeLog typo, fix it. If a file was deleted or
+ renamed, consider adding an appropriate entry to authors-ignored-files,
+ authors-valid-file-names, or authors-renamed-files-alist.
+
+ If necessary, repeat M-x authors after making those changes.
+ Save the "*Authors*" buffer as etc/AUTHORS.
+ Check the diff looks reasonable. Maybe add entries to
+ authors-ambiguous-files or authors-aliases, and repeat.
+ Commit any fixes to ChangeLogs or authors.el.
+
+3. Set the version number (M-x load-file RET admin/admin.el RET, then
+ M-x set-version RET). For a release, add released ChangeLog
+ entries (M-x add-release-logs RET).
+
+ For a pretest, start at version .90. After .99, use .990 (so that
+ it sorts).
+
+ The final pretest should be a release candidate. Set the version
+ number to that of the actual release. Pick a date about a week
+ from now when you intend to make the release. Use M-x add-release-logs
+ to add the ChangeLog entries for that date to the tar file (but
+ not yet to the repository). Name the tar file as
+ emacs-XX.Y-rc1.tar. If all goes well in the following week, you
+ can simply rename the file and use it for the actual release.
+
+4. autoreconf -i -I m4 --force
+ make bootstrap
+
+ make -C etc/refcards
+ make -C etc/refcards clean
+
+5. Copy lisp/loaddefs.el to lisp/ldefs-boot.el.
+
+ Commit etc/AUTHORS, lisp/ldefs-boot.el, and the files changed
+ by M-x set-version. Use a commit log message that bzrmerge.el
+ will ignore (eg "Bump version...").
+ For a release, also commit the ChangeLog files in all directories.
+
+ If someone else made a commit between step 1 and now,
+ you need to repeat from step 4 onwards. (You can commit the files
+ from step 2 and 3 earlier to reduce the chance of this.)
+
+6. ./make-dist --snapshot --no-compress
+
+ Check the contents of the new tar with admin/diff-tar-files
+ against the previous release (if this is the first pretest) or the
+ previous pretest. If you did not make the previous pretest
+ yourself, find it at <ftp://alpha.gnu.org/gnu/emacs/pretest>.
+ Releases are of course at <ftp://ftp.gnu.org/pub/gnu/emacs/>.
+
+ If this is the first pretest of a major release, just comparing
+ with the previous release may overlook many new files. You can try
+ something like `find . | sort' in a clean bzr tree, and compare the
+ results against the new tar contents.
+
+7. tar -xf emacs-NEW.tar; cd emacs-NEW
+ ./configure --prefix=/tmp/emacs && make && make install
+ Use `script' or M-x compile to save the compilation log in
+ compile-NEW.log and compare it against an old one. The easiest way
+ to do that is to visit the old log in Emacs, change the version
+ number of the old Emacs to __, do the same with the new log and do
+ M-x ediff. Especially check that Info files aren't built, and that
+ no autotools (autoconf etc) run.
+
+8. cd EMACS_ROOT_DIR && bzr tag TAG
+ TAG is emacs-XX.Y.ZZ for a pretest, emacs-XX.Y for a release.
+
+9. Decide what compression schemes to offer.
+ For a release, at least gz and xz:
+ gzip --best -c emacs-NEW.tar > emacs-NEW.tar.gz
+ xz -c emacs-NEW.tar > emacs-NEW.tar.xz
+ For pretests, just xz is probably fine (saves bandwidth).
+
+ Now you should upload the files to the GNU ftp server. In order to
+ do that, you must be registered as an Emacs maintainer and have your
+ GPG key acknowledged by the ftp people. For instructions, see
+ http://www.gnu.org/prep/maintain/html_node/Automated-Upload-Registration.html
+ The simplest method to upload is to use the gnulib
+ <http://www.gnu.org/s/gnulib/> script "build-aux/gnupload":
+
+ For a pretest:
+ gnupload [--user your@gpg.key.email] --to alpha.gnu.org:emacs/pretest \
+ FILE.gz FILE.xz ...
+
+ For a release:
+ gnupload [--user your@gpg.key.email] --to ftp.gnu.org:emacs \
+ FILE.gz FILE.xz ...
+
+ You only need the --user part if you have multiple GPG keys and do
+ not want to use the default.
+ Obviously, if you do not have a fast uplink, be prepared for the
+ upload to take a while.
+
+
+ If you prefer to do it yourself rather than use gnupload:
+
+ For each FILE, create a detached GPG binary signature and a
+ clearsigned directive file like this:
+
+ gpg -b FILE
+ echo directory: emacs/pretest > FILE.directive (for a pretest)
+ echo directory: emacs > FILE.directive (for a release)
+ gpg --clearsign FILE.directive
+ Upload by anonymous ftp to ftp://ftp-upload.gnu.org/ the files FILE,
+ FILE.sig, FILE.directive.asc.
+ For a release, place the files in the /incoming/ftp directory.
+ For a pretest, place the files in /incoming/alpha instead, so that
+ they appear on ftp://alpha.gnu.org/.
+
+10. After five minutes, verify that the files are visible at
+ ftp://alpha.gnu.org/gnu/emacs/pretest/ for a pretest, or
+ ftp://ftp.gnu.org/gnu/emacs/ for a release.
+
+ Download them and check the signatures. Check they build.
+
+11. Send an announcement to: emacs-devel, and bcc: info-gnu-emacs@gnu.org.
+ For a pretest, also bcc: platform-testers@gnu.org.
+ (The reason for using bcc: is to make it less likely that people
+ will followup on the wrong list.)
+ See the info-gnu-emacs mailing list archives for the form
+ of past announcements. The first pretest announcement, and the
+ release announcement, should have more detail.
+
+12. For a release, update the Emacs homepage in the web repository.
+ Also update history.html, and add the new NEWS file as NEWS.xx.y.
+ Regenerate the html manuals (use make-manuals from admin.el).
+ If there are new manuals, add appropriate index pages.
HCoop / bpt / emacs.git / blobdiff