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