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 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.
  68     For a release, also commit the ChangeLog files in all directories.
  69
  70 7.  ./make-dist --snapshot --no-compress
  71
  72     Check the contents of the new tar with
  73     admin/diff-tar-files against an older tar file.  Some old pretest
  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/>.
  76
  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
  79     something like `find . | sort' in a clean bzr tree, and compare the
  80     results against the new tar contents.
  81
  82 8.   tar -xf emacs-NEW.tar; cd emacs-NEW
  83      ./configure --prefix=/tmp/emacs && make && make install
  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
  88     M-x ediff.  Especially check that Info files aren't built, and that
  89     no autotools (autoconf etc) run.
  90
  91 9.  cd EMACS_ROOT_DIR && bzr tag TAG
  92     TAG is emacs-XX.Y.ZZ for a pretest, emacs-XX.Y for a release.
  93
  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).
  98
  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
 105     do that, you must be registered as an Emacs maintainer and have your
 106     GPG key acknowledged by the ftp people.  For instructions, see
 107     http://www.gnu.org/prep/maintain/html_node/Automated-Upload-Registration.html
 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:
 129
 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
 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/.
 139
 140 11. After five minutes, verify that the files are visible at
 141     ftp://alpha.gnu.org/gnu/emacs/pretest/ for a pretest, or
 142     ftp://ftp.gnu.org/gnu/emacs/ for a release.
 143
 144     Download them and check the signatures.  Check they build.
 145
 146 12. For a pretest, announce it on emacs-devel and info-gnu-emacs@gnu.org.
 147     Probably should also include the platform-testers list:
 148     https://lists.gnu.org/mailman/listinfo/platform-testers
 149     For a release, also announce it on info-gnu@gnu.org.  (Probably
 150     bcc the info- addresses to make it less likely that people will
 151     followup on those lists.)
 152
 153 13. For a release, update the Emacs homepage in the web repository.
 154     Also add the new NEWS file as NEWS.xx.y.
 155     Maybe regenerate the html manuals, update the FAQ, etc, etc.