> > REMEMBER - EVERY API CHANGE YOU MAKE MEANS I HAVE TO SPEND SEVERAL HOURS > OF WORK ALIGNING THINGS. Plus more hours keeping changes aligning for > every future change too. The thing that jumps out at me about this statement is the implication that 2.2.x is changing and the 'old ways of doing things' are not working. i.e. why are the old classes / methods not available and marked as deprecated.
Our policy is that 2.x code should run on 2.x+1 with deprecation warnings... If you are having to modify 2.1 to match 2.2 then what is is? A version of 2.2 without some bits and with alternative implementations of other bits...? (This is why I have always been very very woried about continued development on the 2.1 branch... it should be in mainenance mode!) > > Should we: > 1. just say "ha ha - fooled you" for the people doing rendering (and > other modules) on 2.1.x. This pretty much means we're calling 2.1.x a > fork. 2.1 is a branch. The moment work not related to bug fixes (is optimization a bug fix?) started it became a fork. I have said all along that I have been very very uncompfortable with the level of development work happening on 2.1.x but the people doing that work assured me they were happy to keep 2.1 and 2.2 synch. These same people now seem to be very un-happy keeping that level of effort up. I can recall no commitment from 2.2 developers to make life easy for 2.1 developers other than ensuring that code written against 2.1 would work on 2.2. (I can well imagine that this is not holding true and if so needs to be addresed urgently) > 2. Actually try to announce, vote, and transition API changes. Agreed this needs to happen, the re-seperation of main into an api only module should make that easier. > PS. And *please* don't auto-format code anymore! I have to agree with that, idealy we should all follow the conventions and use jalopy before commiting code. BUT if that does not happen DO NOT go refomating other peoples code, there is little more anoying that tracking down changes when there are none. (Though diffing with ignore white space switched on can be a life saver!) James ------------------------------------------------------- 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_idv37&alloc_id865&op=click _______________________________________________ Geotools-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/geotools-devel
