Document the release process

* admin/notes/versioning: Add information about RC releases.
* admin/release-process: Document the release process.
* admin/authors.el (authors-ignored-files):
* admin/README: Change FOR-RELEASE to release-process.
* CONTRIBUTE:
* admin/notes/bugtracker: Don't mention FOR-RELEASE.
This commit is contained in:
Xue Fuqiao 2015-11-15 09:35:50 +08:00
parent f8cc14b597
commit 9a4aa0f594
6 changed files with 68 additions and 14 deletions

View file

@ -144,10 +144,10 @@ messages:
"2014-01-16T05:43:35Z!esr@thyrsus.com". Often, "my previous commit"
will suffice.
- There is no need to mention files such as NEWS, MAINTAINERS, and
FOR-RELEASE, or to indicate regeneration of files such as
'configure', in the ChangeLog entry. "There is no need" means you
don't have to, but you can if you want to.
- There is no need to mention files such as NEWS and MAINTAINERS, or
to indicate regeneration of files such as 'configure', in the
ChangeLog entry. "There is no need" means you don't have to, but
you can if you want to.
** Generating ChangeLog entries

View file

@ -12,9 +12,9 @@ what you do when using them.
* Instructions and scripts used to prepare an Emacs release.
** FOR-RELEASE
** release-process
Living list of activities that must be completed before the next release.
The release process used by GNU Emacs.
** make-tarball.txt

View file

@ -267,7 +267,7 @@ Changes to files matching one of the regexps in this list are not listed.")
'("external-lisp"
"lock" "share-lib" "local-lisp"
"noleim-Makefile.in"
"NEWS" "ORDERS" "PROBLEMS" "FAQ" "AUTHORS" "FOR-RELEASE" "TODO" "todo"
"NEWS" "ORDERS" "PROBLEMS" "FAQ" "AUTHORS" "release-process" "TODO" "todo"
"MACHINES" "SERVICE"
"README.unicode" "README.multi-tty" "TUTORIAL.translators"
"NEWS.unicode" "COPYING.DJ" "Makefile.old" "Makefile.am"

View file

@ -140,8 +140,7 @@ you can add an element to gnus-posting-styles to do this automatically, eg:
** To record a bug in the tracker without sending mail to the bug list.
This can be useful to make a note of something discussed on
emacs-devel that needs fixing. In other words, this can be the
equivalent of adding something to FOR-RELEASE.
emacs-devel that needs fixing.
To: quiet@debbugs.gnu.org
[headers end]

View file

@ -9,16 +9,20 @@ Emacs version numbers have the form
"build" increments each time Emacs is built in the same location
(without cleaning) and isn't really part of the version.
bugfix releases increase "minor" by 1.
non-bugfix releases increase "major" by 1, and reset "minor" to 1.
Bugfix releases increase "minor" by 1.
Non-bugfix releases increase "major" by 1, and reset "minor" to 1.
(The division between bugfix and non-bugfix has not always been clear
historically.)
Unreleased (development) versions have an extra "devel" component.
This is a fairly meaningless number that may be unchanged for a long time.
It is normally 50.
When the release process starts, it changes to 90, 91, ...
When the actual release is made, this component is removed.
After we cut the release branch, well make pretest and release
candidate (RC) releases. For pretest releases, the "devel" component
changes to 90, 91, ... When the first RC release is made, this
component is removed. Normally, there is one RC release, unless an
unexpected last-minute problem occurs.
The development version for a new major release has "minor" = 0.
The development version for a new minor release has "minor" = that of

View file

@ -1,7 +1,51 @@
Tasks needed before the next release.
This document describes the release process used by GNU Emacs.
* RELEASE CYCLE
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
branches.
** Phase two: bugfixes
Shortly before this phase, Emacs developers will be devoted to
figuring out what features to include in the next release and what
features to defer to a later release.
At the beginning of this phase, a release branch called "emacs-NN"
("NN" represents the major version number of the new Emacs release)
will be cut from `master'.
This phase is spent fixing bugs and eliminating undocumented new
features on the "emacs-NN" branch.
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.
* RELEASE-CRITICAL BUGS
Emacs uses the "blocking bug(s)" feature of Debbugs for bugs 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:
block 19759 by 123
Change "block" to "unblock" to unblock the bug.
* 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.
** Make sure the necessary sources and scripts for any generated files
are included in the source tarfile. (They don't need to be installed,
so eg admin/ is fine.)
@ -275,6 +319,13 @@ tips.texi
variables.texi
windows.texi
* OTHER INFORMATION
For Emacs's versioning scheme, see `admin/notes/versioning'.
For instructions to create pretest or release tarballs, announcements,
etc., see `admin/make-tarball.txt'.
Local variables:
mode: outline