Just a reminder about what the policy is supposed to be when working on trunk.
The following assumes that current GeoTools version number is 2.5-SNAPSHOT (as
it is the case today):
* Like usual, any privated or package-privated classes or method can change
at anytime without notice.
* On public or protected API:
- Every API documented with a "@since 2.5" Javadoc tag can
change at anytime without notice.
- Every API documented with a "@since 2.4" or lower version and
not @deprecated is commited API. It may be deprecated in 2.5,
but not removed.
- Every API documented as @deprecated since 2.4 or before can be
removed at any time, but we should send a warning on the mailing
first.
Unfortunatly note every GeoTools module follow this policy with rigor, but I
try
to apply it concistently at least in metadata, referencing and coverage modules.
There is however two compatibility break that do not fit in the above policy:
* Application of Java 5 language structure, especially covariant return type,
breaks compatibility for the subclasses of any classes where we applied
covariant return type (but this compile-time error is usually easy to fix),
and may break compatibility for users in some case (but it usually reveal
bugs in the later case).
* We will switch the Unit framework from JSR-108 to JSR-275. I was planing
to apply this switch in February, but it is obviously pushed back to March
since I don't yet have free time... This will break compatibility of any
code using javax.units.Unit.
Martin
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Geotools-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geotools-devel
