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
+6. If there has been a change in who is the Emacs maintainer since
+ the last release, update doc/misc/ack.texi and admin/MAINTAINERS
+ to reflect this. You can commit this separately.
+
+7. ./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
The output of this command might be easier to compare to the
tarball than the one you get from find.
-7. tar xf emacs-NEW.tar; cd emacs-NEW
+8. tar xf emacs-NEW.tar; cd emacs-NEW
./configure --prefix=/tmp/emacs && make check && make install
Use 'script' or M-x compile to save the compilation log in
M-x ediff. Especially check that Info files aren't built, and that
no autotools (autoconf etc) run.
-8. You can now tag the release/pretest and push it together with the
+9. You can now tag the release/pretest and push it together with the
last commit:
cd EMACS_ROOT_DIR && git tag -a TAG -m "Emacs TAG"
git tag -a emacs-28.1-rc1 -m "Emacs 28.1 RC1"
git tag -a emacs-28.1 -m "Emacs 28.1 release"
-9. Decide what compression schemes to offer.
+10. Decide what compression schemes to offer.
For a release, at least gz and xz:
gzip --best --no-name -c emacs-NEW.tar > emacs-NEW.tar.gz
xz -c emacs-NEW.tar > emacs-NEW.tar.xz
For a pretest, place the files in /incoming/alpha instead, so that
they appear on https://alpha.gnu.org/.
-10. After five minutes, verify that the files are visible at
+11. After five minutes, verify that the files are visible at
https://alpha.gnu.org/gnu/emacs/pretest/ for a pretest, or
https://ftp.gnu.org/gnu/emacs/ for a release.
Download them and check the signatures and SHA1/SHA256 checksums.
Check they build (./configure --with-native-compilation).
-11. Send an announcement to: emacs-devel, and bcc: info-gnu-emacs@gnu.org.
+12. 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
(Use e.g. `M-x mml-secure-message-sign' in `message-mode' to sign
an email.)
-12. After a release, update the Emacs pages as described below.
+13. After a release, update the Emacs pages as described below.
-13. After a release, bump the Emacs version on the release branch.
+14. After a release, bump the Emacs version on the release branch.
There is no need to bump the version after a pretest; the version
is bumped before the next pretest or release instead.
@item
Lars Magne Ingebrigtsen was the Emacs (co-)maintainer from Emacs 27.2
-onwards. He did a major redesign of the Gnus news-reader and wrote
+to 29.1. He did a major redesign of the Gnus news-reader and wrote
many of its parts. Several of these are now general components of
Emacs, including: @file{dns.el} for Domain Name Service lookups;
@file{format-spec.el} for formatting arbitrary format strings;
Tomoji Kagatani implemented @file{smtpmail.el}, used for sending out
mail with SMTP.
+@item
+Stefan Kangas was the Emacs (co-)maintainer from 29.2 onwards.
+
@item
Ivan Kanis wrote @file{vc-hg.el}, support for the Mercurial version
control system.
mode for editing VHDL source code.
@item
-John Wiegley was the Emacs maintainer from Emacs 25 onwards. He wrote
-@file{align.el}, a set of commands for aligning text according to
-regular-expression based rules; @file{isearchb.el} for fast buffer
+John Wiegley was the Emacs (co-)maintainer from Emacs 25 to 29.1. He
+wrote @file{align.el}, a set of commands for aligning text according
+to regular-expression based rules; @file{isearchb.el} for fast buffer
switching; @file{timeclock.el}, a package for keeping track of time
spent on projects; the Bahá'í calendar support; @file{pcomplete.el}, a
programmable completion facility; @file{remember.el}, a mode for