David Zwiers wrote:
Jody, my question is more along the lines of when should the project
mature into more of a maintenance stance than r&d. For those of you
who would argue that it has already progressed to a maintenance
stance, then the question is, how often should we phase out api /
replace api / change api (This is a life cycle question). For example
(don't want to single this case out ... there have been numerous
cases), we should ask:
Thanks for the clarification - makes more sense phrased that way.
GeoTools I think is at least a year away from this state. I would say 6
months to make what we have consistent, and 6 months to bring up the
usage documentation to the same level as the developers guide. A lot of
my questions have been towards both these goals.
(Example questions)
1) is the new Style API backwards compatible
Yes - for the style interfaces aka the API. No for the Factory.
2) are any of the additions too close to the old methods (duplicates)
Yes - by intention method compatible with GeoAPI.
3) which methods (any?) are being removed, and how will this affect (1)
None.
The parts that are incompatible are where mistakes were made ... these
things should of been caught in a QA check for 2.1.x - but as with most
everything in main there is nobody responsible for the styling package ...
Jody
-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
_______________________________________________
Geotools-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geotools-devel
