procyberian/emacs
2
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

; * admin/make-tarball.txt: Minor copyedits.

Browse source
This commit is contained in:
Eli Zaretskii 2024-08-16 21:55:37 +03:00
parent 3fc1635783
commit 5c9de704cc
1 changed files with 29 additions and 27 deletions
Download patch file Download diff file Expand all files Collapse all files

56
admin/make-tarball.txt
View file

@ -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 of the format "Bump Emacs version to ...", so that the commit can
be skipped when merging branches (see admin/gitmerge.el). be skipped when merging branches (see admin/gitmerge.el).
The final pretest should be a release candidate. If this is a final pretest before the release:
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 The final pretest should be a release candidate.
one, as described above). Pick a date about a week from now when Before a release candidate is made, the tasks listed in
you intend to make the release. Use M-x add-release-logs from admin/release-process must be completed.
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, Set the version number to that of the actual release (commit in
and delay the final tagging until you actually decide to make a one, as described above). Pick a date about a week from now when
release and announce it. The "git tag" command can tag a specific you intend to make the release. Use M-x add-release-logs from
commit if you give it the SHA1 of that commit, even if additional admin/admin.el to add entries to etc/HISTORY and the ChangeLog
commits have been pushed in the meantime. 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.
Name the tar file as emacs-XX.Y-rc1.tar. If all goes well in the Alternatively, you can commit and tag with the RC tag right away,
following week, you can simply rename the file and use it for the and delay the final tagging until you actually decide to make a
actual release. If you need another release candidate, remember release and announce it. The "git tag" command can tag a specific
to adjust the ChangeLog and etc/HISTORY entries. commit if you give it the SHA1 of that commit, even if additional
commits have been pushed in the meantime.
If you need to change only a file(s) that cannot possibly affect Name the tar file as emacs-XX.Y-rc1.tar. If all goes well in the
the build (README, ChangeLog, NEWS, etc.) then rather than doing following week, you can simply rename the file and use it for the
an entirely new build, it is better to unpack the existing actual release. If you need another release candidate, remember
tarfile, modify the file(s), and tar it back up again. to adjust the ChangeLog and etc/HISTORY entries.
Never replace an existing tarfile! If you need to fix something, If you need to change only a file(s) that cannot possibly affect
always upload it with a different name. 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 4. autoreconf -i -I m4 --force
make bootstrap make bootstrap