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
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
|
XFree86 Version Numbering Schemes
The XFree86 Project, Inc
28 January 2001
Abstract
The version numbering schemes used by XFree86 have changed from
time to time. The schemes used since version 3.3 are explained
here.
1. Releases, Development Streams and Branches
As of the release of version 4.0.2 in December 2000, XFree86 has three
release branches. The main development stream is on the trunk of the CVS
repository. That is where all new development work is done. A stable bugfix
branch for the 4.0.2 release was created at the time of its release, and that
branch is called "xf-4_0_2-branch". Fixes for bugs found in the 4.0.2
release will be added to this branch (as well as the trunk). Similar stable
branches will be created after each full release.
Finally, there is the 3.3.x legacy branch, which is called "xf-3_3-branch".
While this branch is not actively being maintained, it does include some
important post-3.3.6 bug fixes and security updates. Security updates in
particular are usually back-ported to this branch.
XFree86 is planning to make full releases from the main development stream
approximately every six months, in late May and November of each year. The
feature freezes for these releases will be 1 April and 1 October respec-
tively. These are target dates, not a binding commitment. How effectively
these dates can be met will depend to a large degree on the resource avail-
able to XFree86. 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 avail-
ability of resources. 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 4.1.0, scheduled for late May 2001.
The next update release will be 4.0.3. There is no specific schedule for
that, but it is expected to be available some time in February 2001. The
next release on the legacy branch will be 3.3.7. There is currently no
schedule for that release. The 3.3.7 release is likely to be the final
release on that branch.
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.
2. Current (new) Version Numbering Scheme
Starting with the main development branch after 4.0.2, the XFree86 versions
will be numbered according to the scheme outlined here. Both the 4.0.2 sta-
ble branch and the 3.3.x legacy branch will continue to use the previous
scheme, which is outlined in the sections below.
The version numbering format is M.m.P.s, where M is the major version number,
m is the minor version number, P is the patch level, and s is the snapshot
number. Full releases have P set to zero, and it is incremented for each
subsequent bug fix release on the post-release stable branch. The snapshot
number s is present only for between-release snapshots of the development and
stable branches.
2.1 Development Branch
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 snap-
shot. The CVS tag for snapshots is "xf-M_m_P_s". When the development
branch enters feature freeze, the snapshot number is bumped to 900, and a
stable branch is created for the next full release. The branch is called
"xf-M_m-branch". 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 4.1.0:
4.0.99.1
The first snapshot of the pre-4.1 development branch.
4.0.99.23
The twenty-third snapshot of the pre-4.1 development branch.
4.0.99.900
The start of the 4.1 feature freeze, which marks the creation of
the "xf-4_1-branch" branch. That branch is the "stable" branch
for the 4.1.x releases.
4.0.99.903
The third 4.1.0 release candidate.
4.1.0
The 4.1.0 release.
4.1.99.1
The first pre-4.2 development snapshot, which is the first main
branch snapshot after creating the 4.1 stable branch.
2.2 Stable Branch
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 snap-
shots on this branch are considered "release candidates", so the first is
indicated by setting s to 901. The snapshot number is then incremented for
each subsequent release candidate until the update release if finalised. The
patch level value (P) is incremented for each update release.
Here's an example which shows the version number sequence for the 4.1.x sta-
ble branch.
4.0.99.900
The start of the 4.1 feature freeze, which marks the creation of
the "xf-4_1-branch" branch. That branch is the "stable" branch
for the 4.1.x releases.
4.0.99.903
The third 4.1.0 release candidate.
4.1.0
The 4.1.0 release.
4.1.0.901
The first pre 4.1.1 snapshot.
4.1.0.903
The third pre 4.1.1 snapshot, also known as the third 4.1.1
release candidate.
4.1.1
The 4.1.1 release.
4.1.1.901
The first pre 4.1.2 snapshot.
4.1.2
The 4.1.2 release.
3. Version Numbering Scheme for XFree86 4.0.x.
The version numbering format for XFree86 4.0.x releases is M.m.nx, where M is
the major version number (4), m is the minor version number (0), n is the
sub-minor version number, and x is a letter. Full release versions up to and
including 4.0.2 were 4.0, 4.0.1, and 4.0.2. Between-release snapshots are
indicated by including x, a lower case letter. For example, the first
post-4.0.1 snapshot was 4.0.1a. Release candidates have been indicated by
setting x to a one or two letter combination with the first letter being "Z".
For example, 4.0.1Z was the first 4.0.2 release candidate.
The next 4.0.x release will be an update release, not a full release. These
update releases will be indicated by incrementing the sub-minor version num-
ber. So, the first post-4.0.2 update release will be 4.0.3. Between-release
snapshots will continue to be indicated with a lower case letter, so the
first pre-4.0.3 snapshot will be 4.0.2a.
The following example illustrates the release sequence from 4.0 through to
the post-4.0.2 update releases.
4.0
The 4.0 release.
4.0a
The first post-4.0 development snapshot.
4.0f
The sixth post-4.0 development snapshot.
4.0Z
The 4.0.1 release candidate.
4.0.1
The 4.0.1 release.
4.0.1a
The first post-4.0.1 development snapshot.
4.0.1f
The sixth post-4.0.1 development snapshot.
4.0Z
The first 4.0.2 release candidate.
4.0Zb
The third 4.0.2 release candidate.
4.0.2
The 4.0.2 release.
4.0.2a
The first pre-4.0.3 snapshot/release candidate.
4.0.2c
The third pre-4.0.3 snapshot/release candidate.
4.0.3
The 4.0.3 update release.
4.0.3a
The first pre-4.0.4 snapshot/release candidate.
4.0.4
The 4.0.4 update release.
4. Pre-4.0 Development Versions
This section is included mostly for historical reasons.
The development leading up to 4.0 started from version 3.2A, but much of it
happened on a separate development branch. The "new design" work on that
development branch was first folded into the main development branch at ver-
sion 3.9N. Up until the XFree86 CVS was made publicly available, all ver-
sions containing one or more letters were internal development snapshots.
The internal development snapshots continued through the following sequence:
3.9N, 3.9Na, ..., 3.9Nz, 3.9P, 3.9Pa, ..., 3.9Py, 3.9.15, 3.9.15a, ...,
3.9.16, 3.9.16a, ..., 3.9.17, 3.9.17a, ..., 3.9.18, 3.9.18a, ..., 4.0. The
3.9.15, 3.9.16, etc versions were public pre-4.0 beta releases.
5. Version Numbering Scheme for XFree86 3.3.x.
The version numbering format for XFree86 3.3.x releases is M.m.nx, where M is
the major version number (3), m is the minor version number (3), n is the
sub-minor version number, and x is a letter. Between-release snapshots are
indicated by including x, a lower case letter. An exception to this scheme
was the 3.3.3.1 release, which was an update to the 3.3.3 release.
3.3
The 3.3 release.
3.3a
The first post-3.3 development snapshot.
3.3.1
The 3.3.1 release.
3.3.1a
The first post-3.3.1 development snapshot.
3.3.2
The 3.3.2 release.
3.3.2a
The first post-3.3.2 development snapshot.
3.3.3
The 3.3.3 release.
3.3.3a
The first post-3.3.3 development snapshot.
3.3.3.1
The 3.3.3.1 release.
3.3.3.1a
The first post-3.3.3.1 development snapshot.
3.3.4
The 3.3.4 release.
3.3.4a
The first post-3.3.4 snapshot.
3.3.5
The 3.3.5 release.
3.3.5a
The first post-3.3.5 snapshot.
3.3.6
The 3.3.6 release.
3.3.6a
The first post-3.3.6 snapshot.
6. Finding the XFree86 X Server Version From a Client
The XFree86 X servers report a VendorRelease value that matches the XFree86
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 3.3.x versions, the VendorRelease value is Mmnp. That is, version
M.m.n.p has VendorRelease set to M * 1000 + m * 100 + n * 10 + p. Exceptions
to this are: The value wasn't incremented for the 3.3.3.1 release, and for
the 3.3.4 and 3.3.5 releases the value was incorrectly set to Mmn
(M * 100 + m * 10 + n). This was corrected for the 3.3.6 release.
For versions 3.9.15 to 4.0.x, the VendorRelease value is Mmnn. That is, ver-
sion M.m.n has VendorRelease set to M * 1000 + m * 100 + n. There have been
no exceptions to this rule.
For post-4.0.2 development and release versions using the new numbering
scheme, the VendorRelease value is MMmmPPsss. That is, version M.m.P.s has
VendorRelease set to M * 10000000 + m * 100000 + P * 1000 + s. Note: 4.0.3
and any other 4.0.x releases will continue with the Mmnn scheme.
Generated from XFree86: xc/programs/Xserver/hw/xfree86/doc/sgml/Versions.sgml,v 1.1 2001/02/07 18:49:31 dawes Exp $
$XFree86: xc/programs/Xserver/hw/xfree86/doc/Versions,v 1.1.4.1 2001/06/01 18:26:46 dawes Exp $
|
