<!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 and Kevin E. Martin
<date>&reldate;

<ident>
</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 X11R6.7 in March 2004, X.Org has three
release branches.  First is the 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 the current release 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.

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.  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 &nextrelvers;.  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 X11R6.7, 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>XORG-M_m_P_s</tt>".  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 "<tt>XORG-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:

<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.
  <tag><tt>6.7.99.903</tt></tag>
	The third 6.8 release candidate.
  <tag><tt>6.8.0</tt></tag>
	The 6.8 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.  Any snapshots on this branch are considered "release
candidates", which is indicated by setting <tt>s</tt> to a number above
900.  The snapshot number is incremented for each release candidate
until the update release is finalised.  The patch level value
(<tt>P</tt>) is incremented for each update release.

Here's an example which shows a version number sequence for a 6.8.x
stable branch:

<descrip>
  <tag><tt>6.8.0</tt></tag>
	The 6.8 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&nbsp;*&nbsp;10000000&nbsp;+&nbsp;m&nbsp;*&nbsp;100000&nbsp;+&nbsp;P&nbsp;*&nbsp;1000&nbsp;+&nbsp;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>
