Hi Mathias, >> Is there a good reason to not do the changes incrementally? > Yes, there is a very good reason. Every incompatible change causes pain, > no matter how many individual changes it contains.
Indeed. Changing XView to contain that additional method creates pain now. Creating an XView2 now and absorbing it in XView in OOo 4.0 creates pain at a later time. I'd say that the former pain is smaller than the latter, and thus I'd like to implement the first solution, not the second. So, it's not (only) about the pain an XView2 would cause now (which, except in terms of highly subjective "ugliness", might not bee to high - admitted), but also about the maintenance pain it will cause later. It would add yet another item to the "if we ever touch this, then let's do it all at once" pile - making it less likely for this pile to ever be stripped. > In case you don't see it: the biggest pain is caused by the fact that we > have to declare every extension as incompatible in every release where > at least one incompatible change has been made, as there is no way to > find out which types an extension uses (and it may be exactly the one > you have changed). Sorry, but you should know better than this. We already talked about which changes cause which type of annoyance to extensions, and adding a method doesn't invalidate all existing Java extensions, nor Basic nor Python nor JavaScript nor BeanShell extensions. All those will continue to work. So your argument is pointless here, as changing an interface as proposed does only invalidate C++ extensions, and even those only if they use the interface in question. > But if an interface is implemented or used in OOo it's just wild > guessing whether it is used somewhere else and leaves too much room for > discussions. I think that developers working at OOo (API) code for for a decade and more can do very educated guesses about this, and I wouldn't disqualify an opinion backed up by that amount of experience as "wild guessing". > It's my experience that establishing roles with too much preconditions > will cause endless discussions, not in every case, but in many. > So I would prefer to treat every incompatible change in the same way. > I could accept to make one exception: if an API is not implemented IIRC, you already made another exception in another thread where we discussed that, namely you agreed that adding non-optional properties to published services should be allowed. Using your arguments from above, I could say that this shouldn't be allowed, as there could be extensions which implement this service, and thus we would need to invalidate all existing extensions if we ever add such a property. Of course this would be nonsense, as an educated guess would probably tell us that not a single extension in the world exists which implements this service. All in all, I am much less pessimistic than you are about the acceptance of such changes. And that's probably the central question, like with every change: Would it please more users than it would repel? In the concrete case, not repelling users is a matter of having control over what we do (instead of just allowing any kind of change for any release), and that's where we disagree: I think we *are* able to retain that control. So how do we proceed? Who's to finally decide that? Ciao Frank -- - Frank Schönheit, Software Engineer frank.schoenh...@sun.com - - Sun Microsystems http://www.sun.com/staroffice - - OpenOffice.org Base http://dba.openoffice.org - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@api.openoffice.org For additional commands, e-mail: dev-h...@api.openoffice.org
