<html>
<!--
Copyright (C) 2005, 2006 Joe Walnes.
Copyright (C) 2006, 2007 XStream committers.
All rights reserved.
The software in this package is published under the terms of the BSD
style license a copy of which has been included with this distribution in
the LICENSE.txt file.
Created on 29. January 2005 by Joe Walnes
-->
<head>
<title>About Versioning</title>
</head>
<body>
<p>The XStream project follows strict rules that govern its use of version
numbers. The version number of a release indicates how that release
is compatible with previous and future releases.</p>
<p>Version numbers have the form
<var>major</var>.<var>minor</var>.<var>patch</var>. A major
version identifies the product stage of the project. Two libraries with
different major version are designed to work together in the same
application. This implies a major change in the API - either by not
sharing the same types or using a different package name.</p>
<p>The minor version number identifies the API version. A release that
changes the API in a way that breaks backwards compatibility will increment
the minor version number and reset the patch version to zero. The patch
version number identifies the backwards compatible revision of the API. A
change in the minor version will still be mostly backward compatible, but
may need some compatibility settings or slight migration adjustments. The
patch version number identifies revisions that do not change the API
although new API elements may occur or existing API may be deprecated to
prepare users for the next release with a change in the minor version. A
release that fixes bugs or refactors implementation details without changing
the API will have the same minor and major versions as the previous release
and increment the patch number.</p>
<p>A hypothetical example:</p>
<table summary="Hypothetical examples for version numbering">
<tr><td>1.0.0</td><td>First release</td></tr>
<tr><td>1.0.1</td><td>Improves Javadoc comments, fixes bug</td></tr>
<tr><td>1.1.0</td><td>Adds new API elements, may cause some migration</td></tr>
<tr><td>1.1.1</td><td>Adds new API elements, deprecates some API elements</td></tr>
<tr><td>1.1.2</td><td>Fixes bugs</td></tr>
<tr><td>1.2.0</td><td>Adds new API, needs some migration effort and removes deprecated elements</td></tr>
<tr><td>2.0.0</td><td>Complete API redesign, can be used simultanly with 1.x series.</td></tr>
<tr><td>2.0.1</td><td>Deprecates API, fixes bugs</td></tr>
<tr><td>2.1.0</td><td>Adds new API elements</td></tr>
<tr><td>etc.</td><td>etc.</td></tr>
</table>
<h2 id="rc">Release Candidates</h2>
<p>Before a new major or minor release, XStream will make release
candidate (RC) packages available so that users can test them against
their own code. There will be one or more release candidates given the
version <var>major</var>.<var>minor</var>.0 RC<var>n</var>, where the
major and minor version numbers identify the upcoming release and RC1
identifies the first candidate release, RC2 the second, and so on.</p>
<p>A release candidate does not guarantee backward compatibility with
new API features introduced by any previous RC of the same upcoming
version.
A major version RC can change/remove API features introduced in a
previous RC for the same major version; a minor version RC can change
API features introduced by any previous RC of the same upcoming minor
version but guarantees backward compatibility with the previous minor
version.</p>
<h2 id="snapshots">Development Snapshots</h2>
<p>During development, the the developers may publish snapshot packages
from time to time. These are not guaranteed to be complete:
Although the unit tests will all pass the snapshot will probably contain
failing acceptance tests that describe planned or requested features that
have not yet been implemented. Snapshots are identified by the UTC time
at which the package was built. The timestamp has the form
<var>VERSION-YYYYMMDD.hhmmss-n</var>, where VERSION is the upcoming
version, YYYY is the (four-digit) year, MM the month, DD the day, hh the
hour, mm the minute, ss the second and n a sequential number.</p>
<h2 id="internal">Internal Classes</h2>
<p>Many classes are for internal use only and not designed to be used by
end users. These are exempt from the versioning rules above.</p>
<p>Such classes are clearly marked as internal in the source code
headers and are excluded from the published JavaDoc.</p>
<h2 id="versioning">Versioning and Deprecation</h2>
<p>A patch release might deprecate some API features. Deprecated features
will not actually be removed until the next minor release.
A release will never remove API features that have not been deprecated in
a previous release.
</p>
</body>
</html>