1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
| | GNU EMACS VERSIONING -*- org -*-
Ref: https://lists.gnu.org/r/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.
After we cut the release branch, we’ll 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
the previous release.
Emacs contains built-in packages with an own version number, which
could be different from the natural version number of this package
(for example, Tramp). Usually, they are adjusted by the respective
maintainers prior an Emacs release. If a new Emacs version will be
released without a pretest release, for example an emergency release
due to security problems, inform the respective package maintainers in
advance by email, and give them a short period (one day) to adjust the
package version number.
|