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
