Commit c1cd371a authored by Glenn Morris's avatar Glenn Morris
Browse files

* admin/notes/versioning: Relocate and rewrite.

parent 12e8ede7
GNU EMACS VERSIONING -*- org -*-
Ref: http://lists.gnu.org/archive/html/emacs-devel/2014-09/msg00872.html
Emacs version numbers have the form
major.minor[.devel].build
"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.
(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.
The development version for a new major release has "minor" = 0.
The development version for a new minor release has "minor" = that of
the previous release.
GNU EMACS VERSIONING -*- org -*-
The version number scheme of Emacs, including how to determine when to
bump various components of the version number, has evolved over the
years. This file defines the current method, explains why it was
chosen, and lightly documents the previous schemes. It was prompted
by http://lists.gnu.org/archive/html/emacs-devel/2014-09/msg00872.html.
Related info:
- [[file:FOR-RELEASE][FOR-RELEASE]]
- [[file:make-tarball.txt][make-tarball.txt]]
* what: MAJOR.MINOR
This has always been the case (see [[was]], below). MINOR is 1 or more,
usually, the exception being for pretest releases, where there is
an additional trailing ".ALPHA" (e.g., 24.3.95 prior to 24.4).
To determine any release's version, we follow this algorithm:
- If MAJOR-CHANGES, increment MAJOR and set MINOR to 1.
- Otherwise, increment MINOR.
where MAJOR-CHANGES is defined roughly as the union of:
- dropped support for IMPORTANT
- platforms (almost never happens)
- Emacs Lisp features
- non-programming features/packages
- IMPORTANT additions and changes
- Emacs Lisp features
- non-programming features/packages
and IMPORTANT is defined through discussion on the [[http://mail.gnu.org/archive/html/emacs-devel/][emacs-devel]]
mailing list and/or private arm-twisting (although this latter
method is somewhat discouraged :-D).
* why
People expect bumps in MINOR for "minor" changes. This typically
includes bugfixes, doc improvements, or fully-backward-compatible
additions and changes, only.
Anything else is actually IMPORTANT, to the user. [Actually, who
really knows what the user thinks? I certainly don't. --ttn]
* was
TODO (be sure to include "ad-hoc" :-D)
Markdown is supported
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment