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
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
|
<!DOCTYPE linuxdoc PUBLIC "-//XFree86//DTD linuxdoc//EN" [
<!ENTITY % defs SYSTEM "defs.ent"> %defs;
]>
<article>
<title>X.Org and XFree86 Version Numbering Schemes
<author>The XFree86 Project, Inc
<and>Updated for X11R&relvers; by Keith Packard
<date>25 March 2004
<ident>
$Id$
$XFree86: xc/programs/Xserver/hw/xfree86/doc/sgml/Versions.sgml,v 1.3 2002/12/21 03:37:09 dawes Exp $
</ident>
<abstract>
X.Org has adopted the same basic numbering scheme used by the XFree86
Project, Inc. for their releases. The actual numbers are different, but the
basic scheme is the same. This document reflects the policy that X.Org uses.
The version numbering schemes used by XFree86 have changed from time to
time.
</abstract>
<toc>
<sect>Releases, Development Streams and Branches
<p>
As of the release of version 6.7.0 in March 2004, X.Org has three
release branches. First is trunk of the CVS repository. This is the
main development stream, where all new work and work for future releases
is done.
Second is the stable bugfix branch for the latest full release
(&fullrelvers;). It is created around the time of the release. The branch
for this one is called "<tt>&relbranchtag;</tt>". Fixes for bugs found
in the release will be added to this branch (as well as the trunk), and
updates to this release (if any) will be cut from this branch. Similar
stable branches are present for previous full releases.
X.Org is planning to make full releases from the main development
stream at regular intervals in the 6-12 month range. The feature
freezes for these releases will usually be 2-3 months before the release
dates. This general plan is a goal, not a binding commitment. The
actual release intervals and dates will depend to a large degree on the
resource available to X.Org. Full releases consist of full source
code tarballs, plus full binary distributions for a range of supported
platforms. Update/bugfix releases will be made on an as-required basis,
depending also on the availability of resources, and will generally be
limited to serious bug and security fixes. New features will not usually
be added in update releases. Update/bugfix releases will not be full
releases, and will consist of source code patches, plus binary updates
to be layered on top of the previous full release.
The next full release will be version &nextfullrelvers;. There is no
scheduled update release, but if one is needed, the version will be
&nextupdrelvers;.
Aside from actual releases, snapshots of the active release branches
are tagged in the CVS repository from time to time. Each such snapshot
has an identifiable version number.
<sect>Current (new) Version Numbering Scheme
<p>
Starting with the main development branch after 6.7.0, the X.Org
versions are numbered according to the scheme outlined here.
The version numbering format is <tt>M.m.P.s</tt>, where <tt>M</tt> is
the major version number, <tt>m</tt> is the minor version number,
<tt>P</tt> is the patch level, and <tt>s</tt> is the snapshot number.
Full releases have <tt>P</tt> set to zero, and it is incremented for each
subsequent bug fix release on the post-release stable branch. The
snapshot number <tt>s</tt> is present only for between-release snapshots
of the development and stable branches.
<sect1>Development Branch
<p>
Immediately after forming a release stable branch, the patch level number
for the main development branch is bumped to 99, and the snapshot number
is reset. The snapshot number is incremented for each tagged development
snapshot. The CVS tag for snapshots is "<tt>x-M_m_P_s</tt>". When
the development branch enters feature freeze, the snapshot number may be
bumped to 900, and a stable branch may be created for the next full release.
The branch is called "<tt>x-M_m-branch</tt>". The snapshot number is
incremented from there until the release is finalised. Each of these
snapshots is a "release candidate". When the release is finalised, the
minor version is incremented, the patch level is set to zero, and the
snapshot number removed.
Here's an example which shows the version number sequence for the
development leading up to version 6.8.0:
<descrip>
<tag><tt>6.7.99.1</tt></tag>
The first snapshot of the pre-6.8 development branch.
<tag><tt>6.7.99.23</tt></tag>
The twenty-third snapshot of the pre-6.8 development branch.
<tag><tt>6.7.99.900</tt></tag>
The start of the 6.8 feature freeze, which marks the creation of
the "<tt>x-6.8-branch</tt>" branch. That branch is the "stable"
branch for the 6.8.x releases.
<tag><tt>6.7.99.903</tt></tag>
The third 6.8.0 release candidate.
<tag><tt>6.8.0</tt></tag>
The 6.8.0 release.
<tag><tt>6.8.99.1</tt></tag>
The first pre-6.9 development snapshot, which is the first main
branch snapshot after creating the 6.8 stable branch.
</descrip>
<sect1>Stable Branch
<p>
After a full release, the stable branch for the release will be maintained
with bug fixes and important updates until the next full release. All
snapshots on this branch are considered "release candidates", so the
first is indicated by setting <tt>s</tt> to 901. The snapshot number
is then incremented for each subsequent release candidate until the
update release if finalised. The patch level value (<tt>P</tt>) is
incremented for each update release.
Here's an example which shows the version number sequence for the
6.8.x stable branch.
<descrip>
<tag><tt>6.7.99.900</tt></tag>
The start of the 6.8 feature freeze, which marks the creation of
the "<tt>x-6.8-branch</tt>" branch. That branch is the "stable"
branch for the 6.8.x releases.
<tag><tt>6.7.99.903</tt></tag>
The third 6.8.0 release candidate.
<tag><tt>6.8.0</tt></tag>
The 6.8.0 release.
<tag><tt>6.8.0.901</tt></tag>
The first pre 6.8.1 snapshot.
<tag><tt>6.8.0.903</tt></tag>
The third pre 6.8.1 snapshot, also known as the third 6.8.1 release
candidate.
<tag><tt>6.8.1</tt></tag>
The 6.8.1 release.
<tag><tt>6.8.1.901</tt></tag>
The first pre 6.8.2 snapshot.
<tag><tt>6.8.2</tt></tag>
The 6.8.2 release.
</descrip>
<sect>Finding the X.Org X Server Version From a Client
<p>
The X.Org X servers report a <tt>VendorRelease</tt> value that matches
the X.Org version number. There have been some cases of releases where
this value wasn't set correctly. The rules for interpreting this value
as well as the known exceptions are outlined here.
For post-6.7.0 development and release versions using the new numbering
scheme, the <tt>VendorRelease</tt> value is <tt>MMmmPPsss</tt>. That
is, version <tt>M.m.P.s</tt> has <tt>VendorRelease</tt> set to
<tt>M * 10000000 + m * 100000 + P * 1000 + s</tt>.
The following is a code fragment taken from <tt>xdpyinfo.c</tt> that shows
how the <tt>VendorRelease</tt> information can be interpreted.
<tscreen><verb>
if (strstr(ServerVendor(dpy), "X.Org")) {
int vendrel = VendorRelease(dpy);
printf("X.Org version: ");
printf("%d.%d.%d", vendrel / 10000000,
(vendrel / 100000) % 100,
(vendrel / 1000) % 100);
if (vendrel % 1000) {
printf(".%d", vendrel % 1000);
}
}
</verb></tscreen>
</article>
|
