From 6b99b6eb8bc5ee5b7ee8c17a636c9ba154702b5c Mon Sep 17 00:00:00 2001 From: Stefan Kangas Date: Thu, 2 Dec 2021 23:57:23 +0100 Subject: [PATCH] * admin/make-tarball.txt: Various clarifications. --- admin/make-tarball.txt | 33 +++++++++++++++++++++++++++------ 1 file changed, 27 insertions(+), 6 deletions(-) diff --git a/admin/make-tarball.txt b/admin/make-tarball.txt index 22276080c5d..872cb00ca28 100644 --- a/admin/make-tarball.txt +++ b/admin/make-tarball.txt @@ -5,7 +5,7 @@ Instructions to create pretest or release tarballs. -*- coding: utf-8 -*- Steps to take before starting on the first pretest in any release sequence: -0. The release branch (e.g. emacs-26) should already have been made +0. The release branch (e.g. emacs-28) 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. @@ -14,12 +14,13 @@ Steps to take before starting on the first pretest in any release sequence: 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.) + refer to a newer version of Emacs. (This is now done when cutting + the release branch, see admin/release-branch.txt.) Commit cus-edit.el if changed. 3. Remove any old pretests from https://alpha.gnu.org/gnu/emacs/pretest. You can use 'gnupload --delete' (see below for more gnupload details). + (We currently don't bother with this.) General steps (for each step, check for possible errors): @@ -89,7 +90,7 @@ General steps (for each step, check for possible errors): admin/release-process must be completed. 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 + 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 @@ -163,8 +164,15 @@ General steps (for each step, check for possible errors): 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. + something like 'find . | sort' in a clean repository, and + compare the results against the new tar contents. Another + alternative is using something like: + + tar cf - emacs-NEW | tar t -C /tmp | grep -Ev "\.(o|d)$" | sort + + Where emacs-NEW is the directory containing your clean repository. + 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 ./configure --prefix=/tmp/emacs && make check && make install @@ -194,6 +202,14 @@ General steps (for each step, check for possible errors): git tag -a TAG -m "Emacs TAG" SHA1 git push --tags + In the past, we were not always consistent with the annotation + (i.e. -m "Emacs TAG"). The preferred format is like this for a + pretest, release candidate and final release: + + git tag -a emacs-28.0.90 -m "Emacs 28.0.90 pretest" + 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. For a release, at least gz and xz: gzip --best --no-name -c emacs-NEW.tar > emacs-NEW.tar.gz @@ -256,6 +272,11 @@ General steps (for each step, check for possible errors): because replies that invariably are not announcements also get sent out as if they were.) + To create the included SHA1 and SHA256 checksums, run: + + sha1sum emacs-NEW.tar.xz + sha256sum emacs-NEW.tar.xz + 12. After a release, update the Emacs pages as described below. 13. Bump the Emacs version on the release branch. -- 2.39.2