Frank Schönheit wrote: > IMO, something along those lines (not thought to an end): > - We should allow for minor incompatible changes which can be overcome > with re-compiling the client code (like adding properties) > - we should allow for non-minor incompatible changes which need > adjustments in the client code for major updates only > - we should disallow silent semantical changes in the API/implementation > (this one is hard to ensure even today, except by policy, which can > be ignored by its very nature)
I'm still not convinced that every type should be allowed to change. I think that stable types have their value. But we have to find out. What I especially wouldn't like is the following situation: I have written an extension that runs fine in, say, OOo 2.x. I also didn't use any types that have been changed incompatibly in OOo3.0 but as this release is announced to be API-incompatible my extension is not usable reliably. How can we avoid that? How can an extension find out whether it is still compatible to the current OOo version? I hate how it is done in TBird and FFox where extensions are disabled just because the version number changed but still run fine after some manual fiddling in the version information of the extension (something end users shouldn't need to do). Ciao, Mathias -- Mathias Bauer (mba) - Project Lead OpenOffice.org Writer OpenOffice.org Engineering at Sun: http://blogs.sun.com/GullFOSS Please don't reply to "[EMAIL PROTECTED]". I use it for the OOo lists and only rarely read other mails sent to it. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
