root
/
spring-security
mirror of https://github.com/spring-projects/spring-security.git
1
0
Fork 0
Code Issues Actions 24 Packages Projects Releases Wiki Activity

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
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

20
docs/manual/src/docbook/introduction.xml
View File

@ -191,15 +191,17 @@
<title>Release Numbering</title> <title>Release Numbering</title>
<para>It is useful to understand how Spring Security release numbers work, as it will help <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 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 the project. Each release uses a standard triplet of integers: MAJOR.MINOR.PATCH. The
guidelines, which can be viewed at intent is that MAJOR versions are incompatible, large-scale upgrades of the API. MINOR
<literal>http://apr.apache.org/versioning.html</literal>. We quote the introduction versions should largely retain source and binary compatibility with older minor
contained on that page for your convenience:</para> versions, thought there may be some design changes and incompatible udates. PATCH level
<para><quote>Versions are denoted using a standard triplet of integers: MAJOR.MINOR.PATCH. should be perfectly compatible, forwards and backwards, with the possible exception of
The basic intent is that MAJOR versions are incompatible, large-scale upgrades of the changes which are to fix bugs and defects.</para>
API. MINOR versions retain source and binary compatibility with older minor versions, <para>The extent to which you are affected by changes will depend on how tightly integrated
and changes in the PATCH level are perfectly compatible, forwards and your code is. If you are doing a lot of customization you are more likely to be affected
backwards.</quote></para> 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>
<section xml:id="get-spring-security"> <section xml:id="get-spring-security">
<title>Getting Spring Security</title> <title>Getting Spring Security</title>