mirror of
https://git.savannah.gnu.org/git/emacs.git
synced 2024-12-11 09:20:51 +00:00
c27b645956
* Makefile.in (bootstrap-build,generate-ldefs-boot): New targets. (bootstrap): Depend on bootstrap-build. * admin/ldefs-clean.el: New file. * lisp/Makefile.in (compile-first): Depend on loaddefs.el * lisp/ldefs-boot.el: Remove. * lisp/ldefs-boot-auto.el: New file. * lisp/ldefs-boot-manual.el: New file. * lisp/loadup.el: Load ldefs-boot-manual.el. * src/emacs.c (generating_ldefs_boot): New variable. (main): Check whether we are generating ldefs. * src/eval.c (autoload-do-load): Dump autoload forms to stderr when requested. * src/lisp.h (generating_ldefs_boot): New variable. * admin/gitmerge.el, admin/make-tarball.txt, admin/notes/copyright, lisp/Makefile.in, lisp/cus-dep.el, lisp/emacs-lisp/elint.el, lisp/finder.el, lisp/loadup.el, msdos/mainmake.v2: Update reference to ldefs-boot. * admin/update_autogen: Alter mechanism for ldefs-boot generation.
211 lines
9.0 KiB
Plaintext
211 lines
9.0 KiB
Plaintext
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-25) 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.
|
|
|
|
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. git pull # fetch from the repository
|
|
git status # check for locally modified files
|
|
|
|
Ensure that you have a clean, unmodified state.
|
|
If you switched in-place from another branch to the release branch,
|
|
there could be inappropriate generated ignored files left over.
|
|
You might want to use "git status --ignored" to check for such files,
|
|
or some form of "git clean -x". It's probably simpler and safer to
|
|
make a new working directory exclusively for the release branch.
|
|
|
|
2. Regenerate the etc/AUTHORS file:
|
|
M-: (require 'authors) RET
|
|
M-x authors RET
|
|
|
|
(This first updates the current versioned ChangeLog.N)
|
|
|
|
If there is an "*Authors Errors*" buffer, address the issues.
|
|
If there was a ChangeLog typo, fix the relevant entry.
|
|
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 'C-u 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 authors.el.
|
|
|
|
3. Set the version number (M-x load-file RET admin/admin.el RET, then
|
|
M-x set-version 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 entries to etc/HISTORY and the ChangeLog
|
|
file. It's best not to commit these files until the release is
|
|
actually made. Merge the entries from (unversioned) ChangeLog
|
|
into the top of the current versioned ChangeLog.N and commit that
|
|
along with etc/HISTORY. Then you can tag that commit as the
|
|
release.
|
|
|
|
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. If you need another release candidate, remember
|
|
to adjust the ChangeLog and etc/HISTORY entries.
|
|
|
|
If you need to change only a file(s) that cannot possibly affect
|
|
the build (README, ChangeLog, NEWS, etc.) then rather than doing
|
|
an entirely new build, it is better to unpack the existing
|
|
tarfile, modify the file(s), and tar it back up again.
|
|
|
|
Never replace an existing tarfile! If you need to fix something,
|
|
always upload it with a different name.
|
|
|
|
4. autoreconf -i -I m4 --force
|
|
make bootstrap
|
|
|
|
make -C etc/refcards
|
|
make -C etc/refcards clean
|
|
|
|
5. Commit ChangeLog.N, etc/AUTHORS, lisp/ldefs-boot.el, and the
|
|
files changed by M-x set-version.
|
|
|
|
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 repository, 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 && git tag -a TAG && git push origin 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.
|
|
For a release, also bcc: info-gnu@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. After a release, update the Emacs pages as below.
|
|
|
|
|
|
UPDATING THE EMACS WEB PAGES AFTER A RELEASE
|
|
|
|
As soon as possible after a release, the Emacs web pages should be updated.
|
|
Anyone with write access to the Emacs code repository can do this.
|
|
For instructions, see <http://savannah.gnu.org/cvs/?group=emacs>.
|
|
Changes go live more or less as soon as they are committed.
|
|
|
|
The pages to update are:
|
|
|
|
emacs.html (for a new major release, a more thorough update is needed)
|
|
history.html
|
|
add the new NEWS file as news/NEWS.xx.y
|
|
|
|
Use M-x make-manuals from admin/admin.el to regenerate the html
|
|
manuals in manual/. If there are new manuals, add appropriate index
|
|
pages in manual/ and add them to manual/index.html. In the
|
|
manual/html_node directory, delete any old manual pages that are no
|
|
longer present.
|
|
|
|
Tar up the generated html_node/emacs/ and elisp/ directories and update
|
|
the files manual/elisp.html_node.tar.gz and emacs.html_node.tar.gz.
|
|
|
|
Use M-x make-manuals-dist from from admin/admin.el to update the
|
|
manual/texi/ tarfiles.
|
|
|
|
Add compressed copies of the main info pages from the tarfile to manual/info/.
|
|
|
|
Update the refcards/pdf/ and ps/ directories, and also
|
|
refcards/emacs-refcards.tar.gz (use make -C etc/refcards pdf ps dist).
|
|
|
|
Browsing <http://web.cvs.savannah.gnu.org/viewvc/?root=emacs> is one
|
|
way to check for any files that still need updating.
|