components/x11/xorg-docs/src/Versions.txt

   1 X.Org Version Numbering Schemes
   2
   3 The XFree86 Project, Inc
   4
   5 Updated for X.Org by Keith Packard, Kevin E. Martin, and Alan Coopersmith
   6
   7 November 2010
   8
   9 X.Org has adopted the same basic numbering scheme used by the XFree86 Project,
  10 Inc. for their releases. The actual numbers are different, but the basic scheme
  11 is the same. This document reflects the policy that X.Org uses.
  12
  13 ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
  14
  15 Table of Contents
  16
  17 Module Versions
  18 Releases, Development Streams, and Branches
  19 Current Version Numbering Scheme
  20
  21     Development Branch
  22     Stable Branch
  23
  24 Finding the X.Org X Server Version From a Client
  25
  26 Module Versions
  27
  28 Starting with the X11R7.0 release, each module has its own version number. For
  29 those without a natural starting point, the version numbers started at 1.0. For
  30 instance, the X11R7.0 release included the xorg-server 1.0 module. As modules
  31 are released independently from the rest of the window system, the module
  32 version is the most accurate source of version information. For instance, there
  33 are many X server releases in a year, but generally only one window system
  34 release, so an X server version number such as 1.7.7 is more informative than
  35 the X11R7.5 version for the window system “katamari” release.
  36
  37 Unfortunately, up through the X server 1.3 release, the X server used the
  38 Window System version when reporting its version number in log files, the
  39 -version option, and the connection setup string (displayed by xdpyinfo). This
  40 was corrected with X server 1.3, which caused the visible version number string
  41 to appear to jump backwards from 7.2 to 1.3.
  42
  43 Releases, Development Streams, and Branches
  44
  45 X.Org has two release branches for the X server software, and several other
  46 modules with active ongoing development. First is the trunk of the git
  47 repository. This is the main development stream, where all new work and work
  48 for future releases is done.
  49
  50 Second is the stable bugfix branch for the latest full release. It is created
  51 around the time of the release. The branch will be named for the release
  52 version, such as “server-1.9-branch” for the X server 1.9.x series of releases.
  53 Fixes for bugs found in the release will be added to this branch (as well as
  54 the trunk), and updates to this release (if any) will be cut from this branch.
  55 Similar stable branches are present for previous full releases.
  56
  57 The X.Org Foundation is planning to make full releases from the main
  58 development stream at regular intervals in the 6-12 month range. The feature
  59 freezes for these releases will usually be 2-3 months before the release dates.
  60 This general plan is a goal, not a binding commitment. The actual release
  61 intervals and dates will depend to a large degree on the resource available to
  62 X.Org. Update/bugfix releases will be made on an as-required basis, depending
  63 also on the availability of resources, and will generally be limited to serious
  64 bug and security fixes. New features will not usually be added in update
  65 releases.
  66
  67 Aside from actual releases, snapshots of the active release branches are tagged
  68 in the git repository from time to time. Each such snapshot has an identifiable
  69 version number.
  70
  71 Current Version Numbering Scheme
  72
  73 Starting with the main development branch after X11R6.7, the X.Org versions are
  74 numbered according to the scheme outlined here.
  75
  76 The version numbering format is M.m.P.s, where M is the major version number, m
  77 is the minor version number, P is the patch level, and s is the snapshot
  78 number. Full releases have P set to zero, and it is incremented for each
  79 subsequent bug fix release on the post-release stable branch. The snapshot
  80 number s is present only for between-release snapshots of the development and
  81 stable branches.
  82
  83 Development Branch
  84
  85 Immediately after forming a release stable branch, the patch level number for
  86 the main development branch is bumped to 99, and the snapshot number is reset.
  87 The snapshot number is incremented for each tagged development snapshot. The
  88 git tag for snapshots is “xorg-server-M.m.P.s”. When the development branch
  89 enters feature freeze, the snapshot number is bumped to 900. A stable branch
  90 may be created for the next full release at any time after the feature freeze.
  91 When it is, the branch is called “server-M.m-branch”. The snapshot number is
  92 incremented from there until the release is finalised. Each of these snapshots
  93 is a “release candidate”. When the release is finalised, the minor version is
  94 incremented, the patch level is set to zero, and the snapshot number removed.
  95
  96 Here's an example which shows the version number sequence for the development
  97 leading up to version 1.8:
  98
  99 1.7.99.1   The first snapshot of the pre-1.8 development branch.
 100
 101 1.7.99.23  The twenty-third snapshot of the pre-1.8 development branch.
 102
 103 1.7.99.900 The start of the 1.8 feature freeze.
 104
 105 1.7.99.903 The third 1.8 release candidate.
 106
 107 1.8.0      The 1.8 release.
 108
 109 1.8.99.1   The first pre-1.9 development snapshot, which is the first main
 110            branch snapshot after creating the 1.8 stable branch.
 111
 112 Stable Branch
 113
 114 After a full release, the stable branch for the release will be maintained with
 115 bug fixes and important updates until the next full release. Any snapshots on
 116 this branch are considered “release candidates,” which is indicated by setting
 117 s to a number above 900. The snapshot number is incremented for each release
 118 candidate until the update release is finalised. The patch level value (P) is
 119 incremented for each update release.
 120
 121 Here's an example which shows a version number sequence for a 1.8.x stable
 122 branch:
 123
 124 1.8.0     The 1.8 release.
 125
 126 1.8.0.901 The first pre 1.8.1 snapshot.
 127
 128 1.8.0.903 The third pre 1.8.1 snapshot, also known as the third 1.8.1 release
 129           candidate.
 130
 131 1.8.1     The 1.8.1 release.
 132
 133 1.8.1.901 The first pre 1.8.2 snapshot.
 134
 135 1.8.2     The 1.8.2 release.
 136
 137 Finding the X.Org X Server Version From a Client
 138
 139 The X.Org X servers report a VendorRelease value that matches the X.Org version
 140 number. There have been some cases of releases where this value wasn't set
 141 correctly. The rules for interpreting this value as well as the known
 142 exceptions are outlined here.
 143
 144 As noted above, the version reported by VendorRelease changed from the window
 145 system version to the X server version starting in the xorg-server 1.3 release.
 146
 147 For all X.Org development and release versions using this numbering scheme, the
 148 VendorRelease value is MMmmPPsss. That is, version M.m.P.s has VendorRelease
 149 set to M * 10000000 + m * 100000 + P * 1000 + s.
 150
 151 The following is a code fragment taken from xdpyinfo.c that shows how the
 152 VendorRelease information can be interpreted.
 153
 154     if (strstr(ServerVendor(dpy), "X.Org")) {
 155         int vendrel = VendorRelease(dpy);
 156
 157         printf("X.Org version: ");
 158         printf("%d.%d.%d", vendrel / 10000000,
 159                (vendrel /   100000) % 100,
 160                (vendrel /     1000) % 100);
 161         if (vendrel % 1000) {
 162             printf(".%d", vendrel % 1000);
 163         }
 164     }
 165