> Jody, I'm a confused by your statement. Almost any new functionality (and
> some bug fixes) come with API changes if
> we include in the notion of API changes new classes and new methods
> (normally I would limit "API changes" to
> ones that break the library users).
>
In this case (in part due to my refactoring) additional public API was
added. No existing code would be rendered incompatible so I agree the work
can be back ported (and its docs).
I don't remember seeing a negative comment on backwards compatible
> additions to base classes.
>
I have asked people to hold off API changes before, in this case it is a
new public class (an enumeration) which is being added. I understand we are
more lax on the geoserver project.
> Can you clarify why this is making you uncomfortable, and/or relate to
> examples where this has caused harm?
>
It is making me uncomfortable because I feel like I am making an exception,
and because without my refactoring the change would of been self contained
(and not be an exception).
------------------------------------------------------------------------------
Find and fix application performance issues faster with Applications Manager
Applications Manager provides deep performance insights into multiple tiers of
your business applications. It resolves application problems quickly and
reduces your MTTR. Get your free trial! http://pubads.g.doubleclick.net/
gampad/clk?id=1444514301&iu=/ca-pub-7940484522588532
_______________________________________________
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel
