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

; * admin/release-process: Copyedits.

Browse source
This commit is contained in:
Glenn Morris 2016-05-24 08:59:09 -07:00
parent 44a6aed33f
commit bdfbe6deff
1 changed files with 37 additions and 32 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

69
admin/release-process
View file

@ -7,7 +7,7 @@ Each release cycle will be split into two periods.
** Phase one: development
The first phase of the release schedule is the "heads-down" working
period for new features, on the 'master' branch and several feature
period for new features, on the 'master' branch and any needed feature
branches.
** Phase two: fixing and stabilizing the release branch
@ -29,46 +29,61 @@ command to do that, then commit the changes it made and push to
'master'. For major releases, also update the value of
'customize-changed-options-previous-release'.
The 2 main manuals, the User Manual and the Emacs Lisp Manual, need to
be proofread, preferably by at least 2 different persons, and any
uncovered problems fixed. This is a lot of work, so it is advisable
to divide the job between several people (see the checklist near the
end of this file).
Each chapter of the two main manuals, the User Manual and the Emacs
Lisp Manual, should be proofread, preferably by at least two people.
This job is so big that it should be considered a collective
responsibility, not fobbed off on just a few people. After each
chapter is checked, mark off the name(s) of those who checked it in
the checklist near the end of this file.
In parallel to this phase, 'master' can receive new features, to be
released in the next release cycle. From time to time, the master
branches merges bugfix commits from the "emacs-NN" branch.
See admin/gitmerge.el.
* RELEASE-CRITICAL BUGS
Emacs uses the "blocking bug(s)" feature of Debbugs for bugs need to
be addressed in the next release.
Emacs uses the "blocking" feature of Debbugs for bugs that need to be
addressed in the next release.
Currently, bug#19759 is the tracking bug for release of 25.1. Say
bug#123 needs to be fixed for Emacs 25.1. Send a message to
control@debbugs.gnu.org that says:
Currently, bug#19759 is the tracking bug for release of 25.1 and
bug#21966 is the tracking bug for the next release. Say bug#123 needs
to be fixed for Emacs 25.1. Send a message to control@debbugs.gnu.org
that says:
block 19759 by 123
Change "block" to "unblock" to unblock the bug.
Change "block" to "unblock" to remove a bug from the list. Closed
bugs are not listed as blockers, so you do not need to explicitly
unblock one that has been closed. You may need to force an update of
the tracking bug with ctrl-f5/shift-reload to see the latest version.
* TO BE DONE SHORTLY BEFORE RELEASE
** Make sure the Copyright date reflects the current year in the source
files. See 'admin/notes/years' for information about maintaining
copyright years for GNU Emacs.
See 'admin/make-tarball.txt' for the details of making a release or pretest.
** Make sure the Copyright date reflects the current year in all source files.
(This should be done each January anyway, regardless of releases.)
See admin/update-copyright and admin.el's set-copyright.
For more details, see 'admin/notes/years'.
** Make sure the necessary sources and scripts for any generated files
are included in the source tarball. (They don't need to be installed,
so e.g. admin/ is fine.)
** Regenerate AUTHORS by using admin/authors.el
(The instructions are at the beginning of that file.)
so e.g. admin/ is fine.) This is important for legal compliance.
** Remove temporary +++/--- lines in NEWS.
But first make sure there are no unmarked entries, and update the
documentation (or decide no updates are necessary) for those that
aren't.
documentation (or decide no updates are necessary) for those that aren't.
** Try to reorder NEWS: most important things first, related items together.
** For a major release, add a "New in Emacs XX" section to faq.texi.
** cusver-check from admin.el can help find new defcustoms missing
:version tags.
** Add a line to etc/HISTORY for the release version number and date.
** Manuals
Check for node names using problematic characters:
@ -84,8 +99,7 @@ For major releases, rewrite the "Antinews" appendix of the User Manual
previous version. The way to do that is read NEWS, pick up the more
significant changes and new features in the upcoming release, then
describe the "benefits" from losing those features. Be funny, use
humor. The text written for the previous major release can serve as
good example.
humor. The text written for the previous releases can serve as an example.
Check cross-references between the manuals (e.g. from emacs to elisp)
are correct. You can use something like the following in the info
@ -146,10 +160,6 @@ size that the GNU Press are going to use when they print the manuals.
I think this is different to what you get if you just use e.g. 'make
emacs.pdf' (e.g., enable "smallbook").
** Try to reorder NEWS: most important things first, related items together.
** For a major release, add a "New in Emacs XX" section to faq.texi.
** Check the keybindings in the refcards are correct, and add any new ones.
What paper size are the English versions supposed to be on?
On Debian testing, the packages texlive-lang-czechslovak and
@ -171,11 +181,6 @@ pt-br Rodrigo Real
ru Alex Ott
sk Miroslav Vaško
** cusver-check from admin.el can help find new defcustoms missing
:version tags.
** Add a line to etc/HISTORY for the release version number and date.
* BUGS
** Check for modes which bind M-s that conflicts with a new global binding M-s