Pārlūkot izejas kodu

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

Luke Taylor 15 gadi atpakaļ
vecāks
revīzija
d04e37c0c4
1 mainītis faili ar 11 papildinājumiem un 9 dzēšanām
  1. 11 9
      docs/manual/src/docbook/introduction.xml

+ 11 - 9
docs/manual/src/docbook/introduction.xml

@@ -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
-            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>
     <section xml:id="get-spring-security">
     <section xml:id="get-spring-security">
         <title>Getting Spring Security</title>
         <title>Getting Spring Security</title>