diff --git a/docs/manual/src/docbook/introduction.xml b/docs/manual/src/docbook/introduction.xml index 5a50ef99a3..e669685b21 100644 --- a/docs/manual/src/docbook/introduction.xml +++ b/docs/manual/src/docbook/introduction.xml @@ -191,15 +191,17 @@ Release Numbering 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 - http://apr.apache.org/versioning.html. We quote the introduction - contained on that page for your convenience: - 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. + 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. + 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. + You should always test your application thoroughly before rolling out a new + version.
Getting Spring Security