GeoTools jars are versioned as a group with version numbers are based on 3 digits:
Major (first digit), is incremented to indicate that a module has lost full compatibility to earlier versions.
So you can safely upgrade to later versions of a module so long as the major version has not changed.
Minor (second digit) is incremented whenever new features are added.
Modules are forward compatible across minor versions, but usually not backward compatible.
Patch (last digit) is for bug fixes.
It is used to indicate fixes in bugs only. No new features were made and full compatibility is preserved.
GeoTools jars released from trunk are versioned with version number based on 2 digits:
The above is theory. In practice, we released some patch versions that contained new features. We also released minor versions that were not forward compatible with older releases (usually through the removal of deprecated methods). This policy on numbering may be revisited later in order to better match the current practice.
Maven is intimently aware of version numbers (in fact they have been seeing each other for some time).
Maven tracks the following information:
The module version number is set in the <version> element in:
Maven uses this value during the build process to figure out what to call generated jars.
The release process has changed a bit since moving to subversion for details please see How to cut a release under project procedures.
Every public and protected class, interface, method or field should have a @since javadoc tag. If the Geotools 2.2 release is under development, then every new API should be identified with a @since 2.2 tag. For the end user, it means that: