emacs-diffs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

emacs-30 5c9de704cc8: ; * admin/make-tarball.txt: Minor copyedits.


From: Eli Zaretskii
Subject: emacs-30 5c9de704cc8: ; * admin/make-tarball.txt: Minor copyedits.
Date: Fri, 16 Aug 2024 14:55:57 -0400 (EDT)

branch: emacs-30
commit 5c9de704cc8cff861a37158229e0b393598798a4
Author: Eli Zaretskii <eliz@gnu.org>
Commit: Eli Zaretskii <eliz@gnu.org>

    ; * admin/make-tarball.txt: Minor copyedits.
---
 admin/make-tarball.txt | 66 ++++++++++++++++++++++++++------------------------
 1 file changed, 34 insertions(+), 32 deletions(-)

diff --git a/admin/make-tarball.txt b/admin/make-tarball.txt
index 9d3de2fa201..15342319829 100644
--- a/admin/make-tarball.txt
+++ b/admin/make-tarball.txt
@@ -137,38 +137,40 @@ General steps (for each step, check for possible errors):
     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 (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 from
-    admin/admin.el 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
-    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.
+    If this is a final pretest before the release:
+
+      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 (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 from
+      admin/admin.el 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
+      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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]