only on this: > Stefan wrote: "So commit rules will be > more strict in terms of agreement and outlining the absolutely necessity > of those changes and the expected problems with backwards compatibility > [e.g plugins]. I may refer here to emails by Sascha Teichmann. > Up to now there is still the wise saying: "never touch a running system." " > > As long as everyone else has to play by the same rules. If I'm getting > special treatment I should at least know the reason. (I'll gladly > accept suggestions or recommendations that deal with technical issues > in my source code.)
there is no special treatment for you. But I believe there is also a misunderstanding: I/we aggreed on the rules outlined above (only) for the OpenJUMP "core". Here, "core" is meant rather in terms of core classes (e.g. stuff in com.vividsolutions... that are not plugins and config files and so on) and not the openjump sources in general (right now core also includes Paul's additions for the framework in org.openjump. - but only those). TaskFrame and WorkbecnhContext are such core classes. Changes here are "restricted" from my point of view - which may not necessarily hold for "adding" new member functions or fields. However, both need to be discussed in the group. I hope to respond with a second email later. However, in short I may add that Larry hits the nail also from my perspective. ------------------------------------------------------------------------- Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW! Studies have shown that voting for your favorite open source project, along with a healthy diet, reduces your potential for chronic lameness and boredom. Vote Now at http://www.sourceforge.net/community/cca08 _______________________________________________ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
