From: Eli Zaretskii Date: Fri, 16 Aug 2024 18:55:37 +0000 (+0300) Subject: ; * admin/make-tarball.txt: Minor copyedits. X-Git-Url: http://git.eshelyaron.com/gitweb/?a=commitdiff_plain;h=8dfeec88812ec7b885edf25e01d7e3645d9c71eb;p=emacs.git ; * admin/make-tarball.txt: Minor copyedits. (cherry picked from commit 5c9de704cc8cff861a37158229e0b393598798a4) --- 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