Minor changes to doc on version numbering. It's not true that minor versions are source/binary compatible.

This commit is contained in:
Luke Taylor 2010-08-19 23:24:12 +01:00
parent 102bc2d6a0
commit d04e37c0c4
1 changed files with 11 additions and 9 deletions

View File

@ -191,15 +191,17 @@
<title>Release Numbering</title>
<para>It is useful to understand how Spring Security release numbers work, as it will help
you identify the effort (or lack thereof) involved in migrating to future releases of
the project. Officially, we use the Apache Portable Runtime Project versioning
guidelines, which can be viewed at
<literal>http://apr.apache.org/versioning.html</literal>. We quote the introduction
contained on that page for your convenience:</para>
<para><quote>Versions are denoted using a standard triplet of integers: MAJOR.MINOR.PATCH.
The basic intent is that MAJOR versions are incompatible, large-scale upgrades of the
API. MINOR versions retain source and binary compatibility with older minor versions,
and changes in the PATCH level are perfectly compatible, forwards and
backwards.</quote></para>
the project. Each release uses a standard triplet of integers: MAJOR.MINOR.PATCH. The
intent is that MAJOR versions are incompatible, large-scale upgrades of the API. MINOR
versions should largely retain source and binary compatibility with older minor
versions, thought there may be some design changes and incompatible udates. PATCH level
should be perfectly compatible, forwards and backwards, with the possible exception of
changes which are to fix bugs and defects.</para>
<para>The extent to which you are affected by changes will depend on how tightly integrated
your code is. If you are doing a lot of customization you are more likely to be affected
than if you are using a simple namespace configuration.</para>
<para>You should always test your application thoroughly before rolling out a new
version.</para>
</section>
<section xml:id="get-spring-security">
<title>Getting Spring Security</title>