admin/make-tarball.txt

   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 1.  Decide on versions of automake and autoconf, and ensure you will
   9     have them available for the duration of the release process.
  10
  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
  20 1.  `bzr update' (for a bound branch), or `bzr pull'.
  21      bzr status   # check for locally modified files
  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
  27 3.  Regenerate the etc/AUTHORS file:
  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.
  45
  46 4.  Set the version number (M-x load-file RET admin/admin.el RET, then
  47     M-x set-version RET).  For a release, add released ChangeLog
  48     entries (M-x add-release-logs RET).
  49
  50     For a pretest, start at version .90.  After .99, use .990 (so that
  51     it sorts).
  52
  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
  58     emacs-XX.Y-rc1.tar.  If all goes well in the following week, you
  59     can simply rename the file and use it for the actual release.
  60
  61 5.   autoreconf -i -I m4 --force
  62      make bootstrap
  63
  64      make -C etc/refcards
  65      make -C etc/refcards clean
  66
  67 6.  Copy lisp/loaddefs.el to lisp/ldefs-boot.el.
  68
  69     Commit etc/AUTHORS, lisp/ldefs-boot.el, and the files changed
  70     by M-x set-version.
  71     For a release, also commit the ChangeLog files in all directories.
  72
  73 7.  ./make-dist --snapshot --no-compress
  74
  75     Check the contents of the new tar with
  76     admin/diff-tar-files against an older tar file.  Some old pretest
  77     tarballs may be found at <ftp://alpha.gnu.org/gnu/emacs/pretest>;
  78     old release tarballs are at <ftp://ftp.gnu.org/pub/gnu/emacs/>.
  79
  80     If this is the first pretest of a major release, just comparing
  81     with the previous release may overlook many new files.  You can try
  82     something like `find . | sort' in a clean bzr tree, and compare the
  83     results against the new tar contents.
  84
  85 8.   tar -xf emacs-NEW.tar; cd emacs-NEW
  86      ./configure --prefix=/tmp/emacs && make && make install
  87     Use `script' or M-x compile to save the compilation log in
  88     compile-NEW.log and compare it against an old one.  The easiest way
  89     to do that is to visit the old log in Emacs, change the version
  90     number of the old Emacs to __, do the same with the new log and do
  91     M-x ediff.  Especially check that Info files aren't built, and that
  92     no autotools (autoconf etc) run.
  93
  94 9.  cd EMACS_ROOT_DIR && bzr tag TAG
  95     TAG is emacs-XX.Y.ZZ for a pretest, emacs-XX.Y for a release.
  96
  97     Shortly before the release, cut the version branch also, and open
  98     a Savannah support request asking for commits to the new branch to
  99     be sent to the emacs-diffs mailing list (by default, the list
 100     normally only gets commits to the trunk).
 101
 102 10. 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
 107     Now you should upload the files to the GNU ftp server.  In order to
 108     do that, you must be registered as an Emacs maintainer and have your
 109     GPG key acknowledged by the ftp people.  For instructions, see
 110     http://www.gnu.org/prep/maintain/html_node/Automated-Upload-Registration.html
 111     The simplest method is to use the gnulib <http://www.gnu.org/s/gnulib/>
 112     script "build-aux/gnupload" to upload each FILE, like this:
 113
 114     For a pretest:
 115      gnupload [--user your@gpg.key.email] --to alpha.gnu.org:emacs/pretest \
 116        FILE.gz FILE.xz ...
 117
 118     For a release:
 119      gnupload [--user your@gpg.key.email] --to ftp.gnu.org:emacs \
 120        FILE.gz FILE.xz ...
 121
 122     You only need the --user part if you have multiple GPG keys and do
 123     not want to use the default.
 124     Obviously, if you do not have a fast uplink, be prepared for the
 125     upload to take a while.
 126
 127
 128     If you prefer to do it yourself rather than use gnupload:
 129
 130     For each FILE, create a detached GPG binary signature and a
 131     clearsigned directive file like this:
 132
 133      gpg -b FILE
 134      echo directory: emacs/pretest > FILE.directive      (for a pretest)
 135      echo directory: emacs > FILE.directive              (for a release)
 136      gpg --clearsign FILE.directive
 137     Upload by anonymous ftp to ftp://ftp-upload.gnu.org/ the files FILE,
 138     FILE.sig, FILE.directive.asc.
 139     For a release, place the files in the /incoming/ftp directory.
 140     For a pretest, place the files in /incoming/alpha instead, so that
 141     they appear on ftp://alpha.gnu.org/.
 142
 143 11. After five minutes, verify that the files are visible at
 144     ftp://alpha.gnu.org/gnu/emacs/pretest/ for a pretest, or
 145     ftp://ftp.gnu.org/gnu/emacs/ for a release.
 146
 147     Download them and check the signatures.  Check they build.
 148
 149 12. For a pretest, announce it on emacs-devel and info-gnu-emacs@gnu.org.
 150     Probably should also include the platform-testers list:
 151     https://lists.gnu.org/mailman/listinfo/platform-testers
 152     For a release, also announce it on info-gnu@gnu.org.  (Probably
 153     bcc the info- addresses to make it less likely that people will
 154     followup on those lists.)
 155
 156 13. For a release, update the Emacs homepage in the web repository.
 157     Also add the new NEWS file as NEWS.xx.y.
 158     Maybe regenerate the html manuals, update the FAQ, etc, etc.