diff options
Diffstat (limited to 'admin/make-tarball.txt')
| -rw-r--r-- | admin/make-tarball.txt | 107 |
1 files changed, 86 insertions, 21 deletions
diff --git a/admin/make-tarball.txt b/admin/make-tarball.txt index 5125086e881..ae007d76b03 100644 --- a/admin/make-tarball.txt +++ b/admin/make-tarball.txt @@ -33,6 +33,11 @@ General steps (for each step, check for possible errors): or some form of "git clean -x". It's probably simpler and safer to make a new working directory exclusively for the release branch. + If the working directory has subdirectories created when making + previous releases or pretests, remove those subdirectories, as the + command which updates the ChangeLog file might attempt to recurse + there and scan any ChangeLog.* files there. + Make sure the tree is built, or at least configured. That's because some of the commands below run Make, so they need Makefiles to be present. @@ -68,20 +73,29 @@ General steps (for each step, check for possible errors): 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). + .99, use .990 (so that it sorts). Commit the resulting changes + as one, with nothing else included, and using a log message + of the format "Bump Emacs version to ...", so that the commit can + be skipped when merging branches (see admin/gitmerge.el). The final pretest should be a release candidate. Before a release candidate is made, the tasks listed in admin/release-process must be completed. - 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. + Set the version number to that of the actual release (commit in + one, as described above). 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. + + Alternatively, you can commit and tag with the RC tag right away, + and delay the final tagging until you actually decide to make a + release and announce it. The "git tag" command can tag a specific + commit if you give it the SHA1 of that commit, even if additional + commits have been pushed in the meantime. 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 @@ -96,11 +110,11 @@ General steps (for each step, check for possible errors): 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 +4. autoreconf -i -I m4 --force + make bootstrap - make -C etc/refcards - make -C etc/refcards clean + make -C etc/refcards + make -C etc/refcards clean If some of the etc/refcards, especially the non-English ones, fail to build, you probably need to install some TeX/LaTeX packages, in @@ -114,13 +128,18 @@ General steps (for each step, check for possible errors): 5. Copy lisp/loaddefs.el to lisp/ldefs-boot.el. Commit ChangeLog.N, etc/AUTHORS, lisp/ldefs-boot.el, and the - files changed by M-x set-version. + files changed by M-x set-version. The easiest way of doing that + is "C-x v d ROOT-DIR RET", then go to the first modified file, + press 'M' to mark all modified files, and finally 'v' to commit + them. Make sure the commit log message mentions all the changes + in all modified files, as by default 'v' doesn't necessarily do + so. 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 +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 @@ -128,6 +147,14 @@ General steps (for each step, check for possible errors): yourself, find it at <https://alpha.gnu.org/gnu/emacs/pretest>. Releases are of course at <https://ftp.gnu.org/pub/gnu/emacs/>. + ./admin/diff-tar-files emacs-OLD.tar.gz emacs-NEW.tar.gz + + Alternatively: + + tar tJf emacs-OLD.tar.xz | sed -e 's,^[^/]*,,' | sort > old_tmp + tar tJf emacs-NEW.tar.xz | sed -e 's,^[^/]*,,' | sort > new_tmp + diff -u old_tmp new_tmp + 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 @@ -135,6 +162,7 @@ General steps (for each step, check for possible errors): 7. 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 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 @@ -142,8 +170,23 @@ General steps (for each step, check for possible errors): 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. +8. 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 push + git push --tags + + Here TAG is emacs-XX.Y.ZZ for a pretest, emacs-XX.Y for a release. + For a release, if you are producing a release candidate first, use + emacs-XX.Y-rcN (N = 1, 2, ...) when you tar the RC, and add the + actual release tag later, when the official release tarball is + uploaded to ftp.gnu.org. When adding a tag later, it is safer to + use the SHA1 of the last commit which went into the release + tarball, in case there were some intervening commits since then: + + git tag -a TAG -m "Emacs TAG" SHA1 + git push --tags 9. Decide what compression schemes to offer. For a release, at least gz and xz: @@ -207,26 +250,48 @@ General steps (for each step, check for possible errors): because replies that invariably are not announcements also get sent out as if they were.) -12. After a release, update the Emacs pages as below. +12. After a release, update the Emacs pages as described below. +13. Bump the Emacs version on the release branch. + If the released version was XX.Y, use 'set-version' from + admin/admin.el to bump the version on the release branch to + XX.Y.50. Commit the changes. UPDATING THE EMACS WEB PAGES AFTER A RELEASE -As soon as possible after a release, the Emacs web pages should be updated. -(See admin/notes/www for general information.) +As soon as possible after a release, the Emacs web pages at +https://www.gnu.org/software/emacs/ should be updated. (See +admin/notes/www for general information.) 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 +Copy new etc/MACHINES to MACHINES and CONTRIBUTE to CONTRIBUTE For every new release, a banner is displayed on top of the emacs.html page. Uncomment and the release banner in emacs.html. Keep it on the -page for about a month, then comment it again. +page for about a month, then comment it again. The new release banner +looks like this: + + <div class="release-banner"> + <div class="container"> + <h2><em>Emacs 27.1 is out</em>, download it <a href="download.html">here</a>!</h2> + </div> + </div> Regenerate the various manuals in manual/. The scripts admin/make-manuals and admin/upload-manuals summarize the process. +If you have Texinfo installed locally, make-manuals might fail if it +cannot find epsf.tex. In that case define in the environment + + TEXINPUTS=:/path/to/texinfo-tree/doc + +where /path/to/texinfo-tree is the absolute file name of the top-level +directory where you have the Texinfo source tree. Then re-run +make-manuals. + Browsing <https://web.cvs.savannah.gnu.org/viewvc/?root=emacs> is one way to check for any files that still need updating. |