home *** CD-ROM | disk | FTP | other *** search
/ Chip 2001 August - Disc 2 / chip_20018102_hu.iso / linux / X-4.1.0 / doc / versions < prev    next >
Text File  |  2001-06-27  |  11KB  |  300 lines
  1.                       XFree86 Version Numbering Schemes
  2.  
  3.                           The XFree86 Project, Inc
  4.  
  5.                                28 January 2001
  6.  
  7.                                   Abstract
  8.  
  9.      The version numbering schemes used by XFree86 have changed from
  10.      time to time.  The schemes used since version 3.3 are explained
  11.      here.
  12.  
  13. 1.  Releases, Development Streams and Branches
  14.  
  15. As of the release of version 4.0.2 in December 2000, XFree86 has three
  16. release branches.  The main development stream is on the trunk of the CVS
  17. repository.  That is where all new development work is done.  A stable bugfix
  18. branch for the 4.0.2 release was created at the time of its release, and that
  19. branch is called "xf-4_0_2-branch".  Fixes for bugs found in the 4.0.2
  20. release will be added to this branch (as well as the trunk).  Similar stable
  21. branches will be created after each full release.
  22.  
  23. Finally, there is the 3.3.x legacy branch, which is called "xf-3_3-branch".
  24. While this branch is not actively being maintained, it does include some
  25. important post-3.3.6 bug fixes and security updates.  Security updates in
  26. particular are usually back-ported to this branch.
  27.  
  28. XFree86 is planning to make full releases from the main development stream
  29. approximately every six months, in late May and November of each year.  The
  30. feature freezes for these releases will be 1 April and 1 October respec-
  31. tively.  These are target dates, not a binding commitment.  How effectively
  32. these dates can be met will depend to a large degree on the resource avail-
  33. able to XFree86.  Full releases consist of full source code tarballs, plus
  34. full binary distributions for a range of supported platforms.  Update/bugfix
  35. releases will be made on an as-required basis, depending also on the avail-
  36. ability of resources.  Update/bugfix releases will not be full releases, and
  37. will consist of source code patches, plus binary updates to be layered on top
  38. of the previous full release.
  39.  
  40. The next full release will be version 4.1.0, scheduled for late May 2001.
  41. The next update release will be 4.0.3.  There is no specific schedule for
  42. that, but it is expected to be available some time in February 2001.  The
  43. next release on the legacy branch will be 3.3.7.  There is currently no
  44. schedule for that release.  The 3.3.7 release is likely to be the final
  45. release on that branch.
  46.  
  47. Aside from actual releases, snapshots of the active release branches are
  48. tagged in the CVS repository from time to time.  Each such snapshot has an
  49. identifiable version number.
  50.  
  51. 2.  Current (new) Version Numbering Scheme
  52.  
  53. Starting with the main development branch after 4.0.2, the XFree86 versions
  54. will be numbered according to the scheme outlined here.  Both the 4.0.2 sta-
  55. ble branch and the 3.3.x legacy branch will continue to use the previous
  56. scheme, which is outlined in the sections below.
  57.  
  58. The version numbering format is M.m.P.s, where M is the major version number,
  59. m is the minor version number, P is the patch level, and s is the snapshot
  60. number.  Full releases have P set to zero, and it is incremented for each
  61. subsequent bug fix release on the post-release stable branch.  The snapshot
  62. number s is present only for between-release snapshots of the development and
  63. stable branches.
  64.  
  65. 2.1  Development Branch
  66.  
  67. Immediately after forming a release stable branch, the patch level number for
  68. the main development branch is bumped to 99, and the snapshot number is
  69. reset.  The snapshot number is incremented for each tagged development snap-
  70. shot.  The CVS tag for snapshots is "xf-M_m_P_s".  When the development
  71. branch enters feature freeze, the snapshot number is bumped to 900, and a
  72. stable branch is created for the next full release.  The branch is called
  73. "xf-M_m-branch".  The snapshot number is incremented from there until the
  74. release is finalised.  Each of these snapshots is a "release candidate".
  75. When the release is finalised, the minor version is incremented, the patch
  76. level is set to zero, and the snapshot number removed.
  77.  
  78. Here's an example which shows the version number sequence for the development
  79. leading up to version 4.1.0:
  80.  
  81.       4.0.99.1
  82.             The first snapshot of the pre-4.1 development branch.
  83.  
  84.       4.0.99.23
  85.             The twenty-third snapshot of the pre-4.1 development branch.
  86.  
  87.       4.0.99.900
  88.             The start of the 4.1 feature freeze, which marks the creation of
  89.             the "xf-4_1-branch" branch.  That branch is the "stable" branch
  90.             for the 4.1.x releases.
  91.  
  92.       4.0.99.903
  93.             The third 4.1.0 release candidate.
  94.  
  95.       4.1.0
  96.             The 4.1.0 release.
  97.  
  98.       4.1.99.1
  99.             The first pre-4.2 development snapshot, which  is the first main
  100.             branch snapshot after creating the 4.1 stable branch.
  101.  
  102. 2.2  Stable Branch
  103.  
  104. After a full release, the stable branch for the release will be maintained
  105. with bug fixes and important updates until the next full release.  All snap-
  106. shots on this branch are considered "release candidates", so the first is
  107. indicated by setting s to 901.  The snapshot number is then incremented for
  108. each subsequent release candidate until the update release if finalised.  The
  109. patch level value (P) is incremented for each update release.
  110.  
  111. Here's an example which shows the version number sequence for the 4.1.x sta-
  112. ble branch.
  113.  
  114.       4.0.99.900
  115.             The start of the 4.1 feature freeze, which marks the creation of
  116.             the "xf-4_1-branch" branch.  That branch is the "stable" branch
  117.             for the 4.1.x releases.
  118.  
  119.       4.0.99.903
  120.             The third 4.1.0 release candidate.
  121.  
  122.       4.1.0
  123.             The 4.1.0 release.
  124.  
  125.       4.1.0.901
  126.             The first pre 4.1.1 snapshot.
  127.  
  128.       4.1.0.903
  129.             The third pre 4.1.1 snapshot, also known as the third 4.1.1
  130.             release candidate.
  131.  
  132.       4.1.1
  133.             The 4.1.1 release.
  134.  
  135.       4.1.1.901
  136.             The first pre 4.1.2 snapshot.
  137.  
  138.       4.1.2
  139.             The 4.1.2 release.
  140.  
  141. 3.  Version Numbering Scheme for XFree86 4.0.x.
  142.  
  143. The version numbering format for XFree86 4.0.x releases is M.m.nx, where M is
  144. the major version number (4), m is the minor version number (0), n is the
  145. sub-minor version number, and x is a letter.  Full release versions up to and
  146. including 4.0.2 were 4.0, 4.0.1, and 4.0.2.  Between-release snapshots are
  147. indicated by including x, a lower case letter.  For example, the first
  148. post-4.0.1 snapshot was 4.0.1a.  Release candidates have been indicated by
  149. setting x to a one or two letter combination with the first letter being "Z".
  150. For example, 4.0.1Z was the first 4.0.2 release candidate.
  151.  
  152. The next 4.0.x release will be an update release, not a full release.  These
  153. update releases will be indicated by incrementing the sub-minor version num-
  154. ber.  So, the first post-4.0.2 update release will be 4.0.3.  Between-release
  155. snapshots will continue to be indicated with a lower case letter, so the
  156. first pre-4.0.3 snapshot will be 4.0.2a.
  157.  
  158. The following example illustrates the release sequence from 4.0 through to
  159. the post-4.0.2 update releases.
  160.  
  161.       4.0
  162.             The 4.0 release.
  163.  
  164.       4.0a
  165.             The first post-4.0 development snapshot.
  166.  
  167.       4.0f
  168.             The sixth post-4.0 development snapshot.
  169.  
  170.       4.0Z
  171.             The 4.0.1 release candidate.
  172.  
  173.       4.0.1
  174.             The 4.0.1 release.
  175.  
  176.       4.0.1a
  177.             The first post-4.0.1 development snapshot.
  178.  
  179.       4.0.1f
  180.             The sixth post-4.0.1 development snapshot.
  181.  
  182.       4.0Z
  183.             The first 4.0.2 release candidate.
  184.  
  185.       4.0Zb
  186.             The third 4.0.2 release candidate.
  187.  
  188.       4.0.2
  189.             The 4.0.2 release.
  190.  
  191.       4.0.2a
  192.             The first pre-4.0.3 snapshot/release candidate.
  193.  
  194.       4.0.2c
  195.             The third pre-4.0.3 snapshot/release candidate.
  196.  
  197.       4.0.3
  198.             The 4.0.3 update release.
  199.  
  200.       4.0.3a
  201.             The first pre-4.0.4 snapshot/release candidate.
  202.  
  203.       4.0.4
  204.             The 4.0.4 update release.
  205.  
  206. 4.  Pre-4.0 Development Versions
  207.  
  208. This section is included mostly for historical reasons.
  209.  
  210. The development leading up to 4.0 started from version 3.2A, but much of it
  211. happened on a separate development branch.  The "new design" work on that
  212. development branch was first folded into the main development branch at ver-
  213. sion 3.9N.  Up until the XFree86 CVS was made publicly available, all ver-
  214. sions containing one or more letters were internal development snapshots.
  215. The internal development snapshots continued through the following sequence:
  216. 3.9N, 3.9Na, ..., 3.9Nz, 3.9P, 3.9Pa, ..., 3.9Py, 3.9.15, 3.9.15a, ...,
  217. 3.9.16, 3.9.16a, ..., 3.9.17, 3.9.17a, ..., 3.9.18, 3.9.18a, ..., 4.0.  The
  218. 3.9.15, 3.9.16, etc versions were public pre-4.0 beta releases.
  219.  
  220. 5.  Version Numbering Scheme for XFree86 3.3.x.
  221.  
  222. The version numbering format for XFree86 3.3.x releases is M.m.nx, where M is
  223. the major version number (3), m is the minor version number (3), n is the
  224. sub-minor version number, and x is a letter.  Between-release snapshots are
  225. indicated by including x, a lower case letter.  An exception to this scheme
  226. was the 3.3.3.1 release, which was an update to the 3.3.3 release.
  227.  
  228.       3.3
  229.             The 3.3 release.
  230.  
  231.       3.3a
  232.             The first post-3.3 development snapshot.
  233.  
  234.       3.3.1
  235.             The 3.3.1 release.
  236.  
  237.       3.3.1a
  238.             The first post-3.3.1 development snapshot.
  239.  
  240.       3.3.2
  241.             The 3.3.2 release.
  242.  
  243.       3.3.2a
  244.             The first post-3.3.2 development snapshot.
  245.  
  246.       3.3.3
  247.             The 3.3.3 release.
  248.  
  249.       3.3.3a
  250.             The first post-3.3.3 development snapshot.
  251.  
  252.       3.3.3.1
  253.             The 3.3.3.1 release.
  254.  
  255.       3.3.3.1a
  256.             The first post-3.3.3.1 development snapshot.
  257.  
  258.       3.3.4
  259.             The 3.3.4 release.
  260.  
  261.       3.3.4a
  262.             The first post-3.3.4 snapshot.
  263.  
  264.       3.3.5
  265.             The 3.3.5 release.
  266.  
  267.       3.3.5a
  268.             The first post-3.3.5 snapshot.
  269.  
  270.       3.3.6
  271.             The 3.3.6 release.
  272.  
  273.       3.3.6a
  274.             The first post-3.3.6 snapshot.
  275.  
  276. 6.  Finding the XFree86 X Server Version From a Client
  277.  
  278. The XFree86 X servers report a VendorRelease value that matches the XFree86
  279. version number.  There have been some cases of releases where this value
  280. wasn't set correctly.  The rules for interpreting this value as well as the
  281. known exceptions are outlined here.
  282.  
  283. For 3.3.x versions, the VendorRelease value is Mmnp.  That is, version
  284. M.m.n.p has VendorRelease set to M * 1000 + m * 100 + n * 10 + p.  Exceptions
  285. to this are:  The value wasn't incremented for the 3.3.3.1 release, and for
  286. the 3.3.4 and 3.3.5 releases the value was incorrectly set to Mmn
  287. (M * 100 + m * 10 + n).  This was corrected for the 3.3.6 release.
  288.  
  289. For versions 3.9.15 to 4.0.x, the VendorRelease value is Mmnn.  That is, ver-
  290. sion M.m.n has VendorRelease set to M * 1000 + m * 100 + n.  There have been
  291. no exceptions to this rule.
  292.  
  293. For post-4.0.2 development and release versions using the new numbering
  294. scheme, the VendorRelease value is MMmmPPsss.  That is, version M.m.P.s has
  295. VendorRelease set to M * 10000000 + m * 100000 + P * 1000 + s.  Note: 4.0.3
  296. and any other 4.0.x releases will continue with the Mmnn scheme.
  297.  
  298.      Generated from XFree86: xc/programs/Xserver/hw/xfree86/doc/sgml/Versions.sgml,v 1.1 2001/02/07 18:49:31 dawes Exp $
  299.  
  300.