aboutsummaryrefslogtreecommitdiffstats
diff options
context:
space:
mode:
authorThien-Thi Nguyen2014-10-10 09:54:08 +0200
committerThien-Thi Nguyen2014-10-10 09:54:08 +0200
commit28c3bdd8d6cd66cf00c00feae8a34d4893ebd103 (patch)
tree6e1e9aaea0aab25f8f34eb6352aa63dfc5ef4dcd
parenta27cd28f9593138b430938854d7613f9029a94a9 (diff)
downloademacs-28c3bdd8d6cd66cf00c00feae8a34d4893ebd103.tar.gz
emacs-28c3bdd8d6cd66cf00c00feae8a34d4893ebd103.zip
[maint] Start Emacs versioning doc; nfc.
* admin/versioning: New file.
-rw-r--r--admin/versioning49
1 files changed, 49 insertions, 0 deletions
diff --git a/admin/versioning b/admin/versioning
new file mode 100644
index 00000000000..2b4d499fc0a
--- /dev/null
+++ b/admin/versioning
@@ -0,0 +1,49 @@
1GNU EMACS VERSIONING -*- org -*-
2
3The version number scheme of Emacs, including how to determine when to
4bump various components of the version number, has evolved over the
5years. This file defines the current method, explains why it was
6chosen, and lightly documents the previous schemes. It was prompted
7by http://lists.gnu.org/archive/html/emacs-devel/2014-09/msg00872.html.
8
9Releated info:
10- [[file:FOR-RELEASE][FOR-RELEASE]]
11- [[file:make-tarball.txt][make-tarball.txt]]
12
13* what: MAJOR.MINOR
14
15This has always been the case (see [[was]], below). MINOR is 1 or more,
16usually, the exception being for pretest releases, where there is
17an additional trailing ".ALPHA" (e.g., 24.3.95 prior to 24.4).
18
19To determine any release's version, we follow this algorithm:
20
21- If MAJOR-CHANGES, increment MAJOR and set MINOR to 1.
22- Otherwise, increment MINOR.
23
24where MAJOR-CHANGES is defined roughly as the union of:
25
26- dropped support for IMPORTANT
27 - platforms (almost never happens)
28 - Emacs Lisp features
29 - non-programming features/packages
30- IMPORTANT additions and changes
31 - Emacs Lisp features
32 - non-programming features/packages
33
34and IMPORTANT is defined through discussion on the [[http://mail.gnu.org/archive/html/emacs-devel/][emacs-devel]]
35mailing list and/or private arm-twisting (although this latter
36method is somewhat discouraged :-D).
37
38* why
39
40People expect bumps in MINOR for "minor" changes. This typically
41includes bugfixes, doc improvements, or fully-backward-compatible
42additions and changes, only.
43
44Anything else is actually IMPORTANT, to the user. [Actually, who
45really knows what the user thinks? I certainly don't. --ttn]
46
47* was
48
49TODO (be sure to include "ad-hoc" :-D)