How do I fix my extension to work with the new name? It's a plain string. There's no refactoring tool that ensures correctness. Search and replace on source code is not really a wise idea. Manual review is necessary for all occurrences. And how do I make sure I get them all? Maybe there's code such as
if (eventName.endsWith("Load")) I would miss this on my search for "OnLoad". Or maybe the event name is converted to lower case before processing? Should I grep for all occurrences of "load" (ignoring case) in the code and manually review them all? It's a pretty common word $ grep -ir load .|wc -l 6238 in my workspace. Our extension is 90000 lines written by several people over 4 years and the event handling code is among the oldest code that we're most reluctant to touch. Then of course there's the issue that we support all versions of OOo since 2.0, so we can't just replace occurrences of "OnLoad" with the new name. We'll have to change the code to query the OOo version and use the appropriate name. That makes the code harder to maintain and risks introducing bugs into code that works perfectly. If you absolutely want to break the events API, then do it properly and do away with the use of plain strings as event identifiers and replace them with constants/enums. Regarding "no commitment to backwards compatibility". This was not just about API but about OOo in general. Off-hand I remember 2 instances when we have had to change our extension because OOo changed in an incompatible way. One was the change of the classpath of the classloader loading the extension, the other was the URE-separation that required the use of new bootstrap code. But I know there was at least one other instance. So we have 6 OOo versions (not counting 3rd digit versions) released since 2.0 and 3 incompatible changes. That's 1 in 2 versions. And the attitude of the developers behind these changes is always that it's okay to do this whenever it can improve OOo in some way no matter how minor. There definitely is no commitment to backwards compatibility as far as I can see. You telling me otherwise is like saying "Hey, you should be happy that we don't break your extension with *every* new minor version." Well, as a matter of fact, if we include unintentional regressions in our count, then you do break our extension almost every time you release a new version. Regarding "just a recompile": This argument to play down the severance of an API change makes several assumptions: You're assuming a) that an extension is actively being developed. Well, there are extensions that are finished, with a complete feature set and no remaining bugs and whose developers have moved on to other projects or left the company. Or a company may have decided to cease selling an extension because the profit margin is too thin. Or.... b) that the extension is free (in whatever sense). If it isn't, then "just a recompile" translates to "users are forced to purchase updates just to keep using the extension" c) that deployment costs are negligible. Even if an extension update is available for free, it has to be deployed. Our extension is being used on several 1000 desktops managed by over a dozen independent IT departments working by their own update schedules. Update deployment alone is a challenge and admins are often reluctant to deploy new versions of more than 1 complex and work-critical component at the same time. So telling them "you have to up the extension version at the same time you deploy the new OOo version" doesn't go over well and they come complaining to us for not making our extension compatible with new OOo versions. d) that the developers/users become aware of the need to recompile soon enough to plan accordingly. Even if there were a low-traffic mailing list for just the things I absolutely need to know, a mailing list for which I know that I must read every message, there's still the problem that your notion of "soon enough" will often diverge from my notion of "soon enough" which again will diverge from my customer's notion of "soon enough". Matthias --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@api.openoffice.org For additional commands, e-mail: dev-h...@api.openoffice.org