<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml"><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /><title>X.Org Version Numbering Schemes</title><meta name="generator" content="DocBook XSL Stylesheets Vsnapshot_9276" /><meta name="description" content="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." /><style xmlns="" type="text/css">/*
* Copyright (c) 2011 Gaetan Nadon
* Copyright (c) 2010, Oracle and/or its affiliates. All rights reserved.
*
* Permission is hereby granted, free of charge, to any person obtaining a
* copy of this software and associated documentation files (the "Software"),
* to deal in the Software without restriction, including without limitation
* the rights to use, copy, modify, merge, publish, distribute, sublicense,
* and/or sell copies of the Software, and to permit persons to whom the
* Software is furnished to do so, subject to the following conditions:
*
* The above copyright notice and this permission notice (including the next
* paragraph) shall be included in all copies or substantial portions of the
* Software.
*
* THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
* IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
* FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
* THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
* LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
* FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
* DEALINGS IN THE SOFTWARE.
*/
/*
* Shared stylesheet for X.Org documentation translated to HTML format
* http://www.sagehill.net/docbookxsl/UsingCSS.html
* http://www.w3schools.com/css/default.asp
* https://addons.mozilla.org/en-US/firefox/addon/web-developer/developers
* https://addons.mozilla.org/en-US/firefox/addon/font-finder/
*/
/*
* The sans-serif fonts are considered more legible on a computer screen
* http://dry.sailingissues.com/linux-equivalents-verdana-arial.html
*
*/
body {
font-family: "Bitstream Vera Sans", "DejaVu Sans", Tahoma, Geneva, Arial, Sans-serif;
/* In support of using "em" font size unit, the w3c recommended method */
font-size: 100%;
}
/*
* Selection: all elements requiring mono spaced fonts.
*
* The family names attempt to match the proportionally spaced font
* family names such that the same font name is used for both.
* We'd like to use Bitstream, for example, in both proportionally and
* mono spaced font text.
*/
.command,
.errorcode,
.errorname,
.errortype,
.filename,
.funcsynopsis,
.function,
.parameter,
.programlisting,
.property,
.screen,
.structname,
.symbol,
.synopsis,
.type
{
font-family: "Bitstream Vera Sans Mono", "DejaVu Sans Mono", Courier, "Liberation Mono", Monospace;
}
/*
* Books have a title page, a preface, some chapters and appendices,
* a glossary, an index and a bibliography, in that order.
*
* An Article has no preface and no chapters. It has sections, appendices,
* a glossary, an index and a bibliography.
*/
/*
* Selection: book main title and subtitle
*/
div.book>div.titlepage h1.title,
div.book>div.titlepage h2.subtitle {
text-align: center;
}
/*
* Selection: article main title and subtitle
*/
div.article>div.titlepage h2.title,
div.article>div.titlepage h3.subtitle,
div.article>div.sect1>div.titlepage h2.title,
div.article>div.section>div.titlepage h2.title {
text-align: center;
}
/*
* Selection: various types of authors and collaborators, individuals or corporate
*
* These authors are not always contained inside an authorgroup.
* They can be contained inside a lot of different parent types where they might
* not be centered.
* Reducing the margin at the bottom makes a visual separation between authors
* We specify here the ones on the title page, others may be added based on merit.
*/
div.titlepage .authorgroup,
div.titlepage .author,
div.titlepage .collab,
div.titlepage .corpauthor,
div.titlepage .corpcredit,
div.titlepage .editor,
div.titlepage .othercredit {
text-align: center;
margin-bottom: 0.25em;
}
/*
* Selection: the affiliation of various types of authors and collaborators,
* individuals or corporate.
*/
div.titlepage .affiliation {
text-align: center;
}
/*
* Selection: product release information (X Version 11, Release 7)
*
* The releaseinfo element can be contained inside a lot of different parent
* types where it might not be centered.
* We specify here the one on the title page, others may be added based on merit.
*/
div.titlepage p.releaseinfo {
font-weight: bold;
text-align: center;
}
/*
* Selection: publishing date
*/
div.titlepage .pubdate {
text-align: center;
}
/*
* The legal notices are displayed in smaller sized fonts
* Justification is only supported in IE and therefore not requested.
*
*/
.legalnotice {
font-size: small;
font-style: italic;
}
/*
* For documentation having multiple licenses, the copyright and legalnotice
* elements sequence cannot instantiated multiple times.
* The copyright notice and license text are therefore coded inside a legalnotice
* element. The role attribute on the paragraph is used to allow styling of the
* copyright notice text which should not be italicized.
*/
p.multiLicensing {
font-style: normal;
font-size: medium;
}
/*
* Selection: book or article main ToC title
* A paragraph is generated for the title rather than a level 2 heading.
* We do not want to select chapters sub table of contents, only the main one
*/
div.book>div.toc>p,
div.article>div.toc>p {
font-size: 1.5em;
text-align: center;
}
/*
* Selection: major sections of a book or an article
*
* Unlike books, articles do not have a titlepage element for appendix.
* Using the selector "div.titlepage h2.title" would be too general.
*/
div.book>div.preface>div.titlepage h2.title,
div.book>div.chapter>div.titlepage h2.title,
div.article>div.sect1>div.titlepage h2.title,
div.article>div.section>div.titlepage h2.title,
div.book>div.appendix>div.titlepage h2.title,
div.article>div.appendix h2.title,
div.glossary>div.titlepage h2.title,
div.index>div.titlepage h2.title,
div.bibliography>div.titlepage h2.title {
/* Add a border top over the major parts, just like printed books */
/* The Gray color is already used for the ruler over the main ToC. */
border-top-style: solid;
border-top-width: 2px;
border-top-color: Gray;
/* Put some space between the border and the title */
padding-top: 0.2em;
text-align: center;
}
/*
* A Screen is a verbatim environment for displaying text that the user might
* see on a computer terminal. It is often used to display the results of a command.
*
* http://www.css3.info/preview/rounded-border/
*/
.screen {
background: #e0ffff;
border-width: 1px;
border-style: solid;
border-color: #B0C4DE;
border-radius: 1.0em;
/* Browser's vendor properties prior to CSS 3 */
-moz-border-radius: 1.0em;
-webkit-border-radius: 1.0em;
-khtml-border-radius: 1.0em;
margin-left: 1.0em;
margin-right: 1.0em;
padding: 0.5em;
}
/*
* Emphasis program listings with a light shade of gray similar to what
* DocBook XSL guide does: http://www.sagehill.net/docbookxsl/ProgramListings.html
* Found many C API docs on the web using like shades of gray.
*/
.programlisting {
background: #F4F4F4;
border-width: 1px;
border-style: solid;
border-color: Gray;
padding: 0.5em;
}
/*
* Emphasis functions synopsis using a darker shade of gray.
* Add a border such that it stands out more.
* Set the padding so the text does not touch the border.
*/
.funcsynopsis, .synopsis {
background: #e6e6fa;
border-width: 1px;
border-style: solid;
border-color: Gray;
clear: both;
margin: 0.5em;
padding: 0.25em;
}
/*
* Selection: paragraphs inside synopsis
*
* Removes the default browser margin, let the container set the padding.
* Paragraphs are not always used in synopsis
*/
.funcsynopsis p,
.synopsis p {
margin: 0;
padding: 0;
}
/*
* Selection: variable lists, informal tables and tables
*
* Note the parameter name "variablelist.as.table" in xorg-xhtml.xsl
* A table with rows and columns is constructed inside div.variablelist
*
* Set the left margin so it is indented to the right
* Display informal tables with single line borders
*/
table {
margin-left: 0.5em;
border-collapse: collapse;
}
/*
* Selection: paragraphs inside tables
*
* Removes the default browser margin, let the container set the padding.
* Paragraphs are not always used in tables
*/
td p {
margin: 0;
padding: 0;
}
/*
* Add some space between the left and right column.
* The vertical alignment helps the reader associate a term
* with a multi-line definition.
*/
td, th {
padding-left: 1.0em;
padding-right: 1.0em;
vertical-align: top;
}
.warning {
border: 1px solid red;
background: #FFFF66;
padding-left: 0.5em;
}
</style></head><body><div class="article"><div class="titlepage"><div><div><h2 class="title"><a id="Versions"></a>X.Org Version Numbering Schemes</h2></div><div><h3 class="corpauthor">
The XFree86 Project, Inc
</h3></div><div><h3 class="corpauthor">
Updated for X.Org by Keith Packard, Kevin E. Martin, and Alan Coopersmith
</h3></div><div><p class="pubdate">November 2010</p></div><div><div class="abstract"><p>
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.
</p></div></div></div><hr /></div><div class="toc"><p><strong>Table of Contents</strong></p><dl><dt><span class="sect1"><a href="#Module_Versions">Module Versions</a></span></dt><dt><span class="sect1"><a href="#Releases_Development_Streams_and_Branches">Releases, Development Streams, and Branches</a></span></dt><dt><span class="sect1"><a href="#Current_Version_Numbering_Scheme">Current Version Numbering Scheme</a></span></dt><dd><dl><dt><span class="sect2"><a href="#Development_Branch">Development Branch</a></span></dt><dt><span class="sect2"><a href="#Stable_Branch">Stable Branch</a></span></dt></dl></dd><dt><span class="sect1"><a href="#Finding_the_X.Org_X_Server_Version_From_a_Client">Finding the X.Org X Server Version From a Client</a></span></dt></dl></div><div class="sect1"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="Module_Versions"></a>Module Versions</h2></div></div></div><p>
Starting with the X11R7.0 release, each module has its own version number.
For those without a natural starting point, the version numbers started at
1.0. For instance, the X11R7.0 release included the xorg-server 1.0
module. As modules are released independently from the rest of the
window system, the module version is the most accurate source of version
information. For instance, there are many X server releases in a year,
but generally only one window system release, so an X server version number
such as 1.7.7 is more informative than the X11R7.5 version for the window
system <span class="quote">“<span class="quote">katamari</span>”</span> release.
</p><p>
Unfortunately, up through the X server 1.3 release, the X server
used the Window System version when reporting its version number
in log files, the -version option, and the connection setup string
(displayed by xdpyinfo). This was corrected with X server 1.3, which
caused the visible version number string to appear to jump backwards
from 7.2 to 1.3.
</p></div><div class="sect1"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="Releases_Development_Streams_and_Branches"></a>Releases, Development Streams, and Branches</h2></div></div></div><p>
X.Org has two release branches for the X server software, and several
other modules with active ongoing development.
First is the trunk of the git repository. This is
the main development stream, where all new work and work for future
releases is done.
</p><p>
Second is the stable bugfix branch for the latest full release. It is
created around the time of the release. The branch will be named for the
release version, such as <span class="quote">“<span class="quote"><code class="literal">server-1.9-branch</code></span>”</span>
for the X server 1.9.x series of releases.
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.
</p><p>
The X.Org Foundation 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.
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.
</p><p>
Aside from actual releases, snapshots of the active release branches
are tagged in the git repository from time to time. Each such snapshot
has an identifiable version number.
</p></div><div class="sect1"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="Current_Version_Numbering_Scheme"></a>Current Version Numbering Scheme</h2></div></div></div><p>
Starting with the main development branch after X11R6.7, the X.Org
versions are numbered according to the scheme outlined here.
</p><p>
The version numbering format is <code class="literal">M.m.P.s</code>,
where <em class="replaceable"><code>M</code></em> is the major version number,
<em class="replaceable"><code>m</code></em> is the minor version number,
<em class="replaceable"><code>P</code></em> is the patch level, and
<em class="replaceable"><code>s</code></em> is the snapshot number.
Full releases have <em class="replaceable"><code>P</code></em> set to zero, and it is
incremented for each subsequent bug fix release on the post-release
stable branch. The snapshot number <em class="replaceable"><code>s</code></em> is
present only for between-release snapshots of the development and
stable branches.
</p><div class="sect2"><div class="titlepage"><div><div><h3 class="title"><a id="Development_Branch"></a>Development Branch</h3></div></div></div><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 git tag for snapshots is
<span class="quote">“<span class="quote"><code class="literal">xorg-server-M.m.P.s</code></span>”</span>.
When the development branch enters feature
freeze, the snapshot number is bumped to 900. A stable branch may be
created for the next full release at any time after the feature freeze.
When it is, the branch is called
<span class="quote">“<span class="quote"><code class="literal">server-M.m-branch</code></span>”</span>. The
snapshot number is incremented from there until the release is
finalised. Each of these snapshots is a <span class="quote">“<span class="quote">release candidate</span>”</span>. When the
release is finalised, the minor version is incremented, the patch level
is set to zero, and the snapshot number removed.
</p><p>
Here's an example which shows the version number sequence for the
development leading up to version 1.8:
</p><p>
</p><div class="variablelist"><table border="0" class="variablelist"><colgroup><col align="left" valign="top" /></colgroup><tbody><tr><td><p><span class="term"><code class="literal">1.7.99.1</code></span></p></td><td><p>
The first snapshot of the pre-1.8 development branch.
</p></td></tr><tr><td><p><span class="term"><code class="literal">1.7.99.23</code></span></p></td><td><p>
The twenty-third snapshot of the pre-1.8 development branch.
</p></td></tr><tr><td><p><span class="term"><code class="literal">1.7.99.900</code></span></p></td><td><p>
The start of the 1.8 feature freeze.
</p></td></tr><tr><td><p><span class="term"><code class="literal">1.7.99.903</code></span></p></td><td><p>
The third 1.8 release candidate.
</p></td></tr><tr><td><p><span class="term"><code class="literal">1.8.0</code></span></p></td><td><p>
The 1.8 release.
</p></td></tr><tr><td><p><span class="term"><code class="literal">1.8.99.1</code></span></p></td><td><p>
The first pre-1.9 development snapshot, which is the first main
branch snapshot after creating the 1.8 stable branch.
</p></td></tr></tbody></table></div><p>
</p></div><div class="sect2"><div class="titlepage"><div><div><h3 class="title"><a id="Stable_Branch"></a>Stable Branch</h3></div></div></div><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. Any snapshots on this branch are considered <span class="quote">“<span class="quote">release
candidates,</span>”</span> which is indicated by setting <em class="replaceable"><code>s</code></em>
to a number above
900. The snapshot number is incremented for each release candidate
until the update release is finalised. The patch level value
(<em class="replaceable"><code>P</code></em>) is incremented for each update release.
</p><p>
Here's an example which shows a version number sequence for a 1.8.x
stable branch:
</p><p>
</p><div class="variablelist"><table border="0" class="variablelist"><colgroup><col align="left" valign="top" /></colgroup><tbody><tr><td><p><span class="term"><code class="literal">1.8.0</code></span></p></td><td><p>
The 1.8 release.
</p></td></tr><tr><td><p><span class="term"><code class="literal">1.8.0.901</code></span></p></td><td><p>
The first pre 1.8.1 snapshot.
</p></td></tr><tr><td><p><span class="term"><code class="literal">1.8.0.903</code></span></p></td><td><p>
The third pre 1.8.1 snapshot, also known as the third 1.8.1 release
candidate.
</p></td></tr><tr><td><p><span class="term"><code class="literal">1.8.1</code></span></p></td><td><p>
The 1.8.1 release.
</p></td></tr><tr><td><p><span class="term"><code class="literal">1.8.1.901</code></span></p></td><td><p>
The first pre 1.8.2 snapshot.
</p></td></tr><tr><td><p><span class="term"><code class="literal">1.8.2</code></span></p></td><td><p>
The 1.8.2 release.
</p></td></tr></tbody></table></div><p>
</p></div></div><div class="sect1"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="Finding_the_X.Org_X_Server_Version_From_a_Client"></a>Finding the X.Org X Server Version From a Client</h2></div></div></div><p>
The X.Org X servers report a <code class="function">VendorRelease</code> 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.
</p><p>
As noted above, the version reported by <code class="function">VendorRelease</code>
changed from the window system version to the X server version starting in
the xorg-server 1.3 release.
</p><p>
For all X.Org development and release versions using this numbering
scheme, the <code class="function">VendorRelease</code> value is
<em class="replaceable"><code>MMmmPPsss</code></em>. That is, version
<em class="replaceable"><code>M.m.P.s</code></em> has <code class="function">VendorRelease</code> set to
<code class="code">M * 10000000 + m * 100000 + P * 1000 + s</code>.
</p><p>
The following is a code fragment taken from <code class="filename">xdpyinfo.c</code>
that shows how the <code class="function">VendorRelease</code> information can be
interpreted.
</p><p>
</p><pre class="programlisting">
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);
}
}
</pre><p>
</p></div></div></body></html>