admin/versioning

   1 GNU EMACS VERSIONING                                   -*- org -*-
   2
   3 The version number scheme of Emacs, including how to determine when to
   4 bump various components of the version number, has evolved over the
   5 years.  This file defines the current method, explains why it was
   6 chosen, and lightly documents the previous schemes.  It was prompted
   7 by http://lists.gnu.org/archive/html/emacs-devel/2014-09/msg00872.html.
   8
   9 Releated info:
  10 - [[file:FOR-RELEASE][FOR-RELEASE]]
  11 - [[file:make-tarball.txt][make-tarball.txt]]
  12
  13 * what: MAJOR.MINOR
  14
  15 This has always been the case (see [[was]], below).  MINOR is 1 or more,
  16 usually, the exception being for pretest releases, where there is
  17 an additional trailing ".ALPHA" (e.g., 24.3.95 prior to 24.4).
  18
  19 To 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
  24 where 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
  34 and IMPORTANT is defined through discussion on the [[http://mail.gnu.org/archive/html/emacs-devel/][emacs-devel]]
  35 mailing list and/or private arm-twisting (although this latter
  36 method is somewhat discouraged :-D).
  37
  38 * why
  39
  40 People expect bumps in MINOR for "minor" changes.  This typically
  41 includes bugfixes, doc improvements, or fully-backward-compatible
  42 additions and changes, only.
  43
  44 Anything else is actually IMPORTANT, to the user.  [Actually, who
  45 really knows what the user thinks?  I certainly don't. --ttn]
  46
  47 * was
  48
  49 TODO (be sure to include "ad-hoc" :-D)