X-Git-Url: https://git.hcoop.net/bpt/emacs.git/blobdiff_plain/1259009aa17da6dc038afff96963f6d9bbd3b8e1..refs/heads/wip:/admin/make-tarball.txt diff --git a/admin/make-tarball.txt b/admin/make-tarball.txt dissimilarity index 65% index 06793b3109..a2e8a9e7da 100644 --- a/admin/make-tarball.txt +++ b/admin/make-tarball.txt @@ -1,104 +1,161 @@ -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. Edit configure.in so that maintainer-mode is off by default. - (FIXME - need to find a better way of dealing with this. - Or maybe it's fine and indeed correct to leave it on? - See http://lists.gnu.org/archive/html/emacs-devel/2011-03/msg00859.html - and subsequent.) - - 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 ; - old release tarballs are at . - - 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_PRETEST_XX_YY_ZZZ for a pretest, EMACS_XX_YY 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. Mail - for instructions. - - 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. +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 . + Releases are of course at . + + 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 + 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.