Thorsten Behrens wrote: > I'm talking about _every_ release. To reiterate: we cannot rely on > _any_ extension (except the most trivial ones, or those that don't use > API at all) running correctly with a new release, without somehow > assuring that API contracts haven't changed. We can achieve this by > either QAing all known extensions against the new release, or by very > strict API testing, or by effectively forbidding any changes to code > paths reachable from API calls. Mozilla does the former, and the > approach appears to be the most feasible to me.
No, seen from the extensions I use that is not entirely true. Extensions are "tested" ;-) for every major release but not for every release. Many extension developers rely on compatibility on a major release code line. This is expressed by e.g. "2.0.x" in the version file. That means to me "this extension should run as long as the API is guaranteed to be stable" (what AFAIK mozilloid apps do for a major code line). So in case we keep our API compatible or at least identifiable parts of it that allow extensions to stay "API compatible" I see the current approach as feasible. If changed behavior created a problem I would treat this as a bug, in the same way as a regression caused by an "unexpected side effect" of changes in a used library. No fundamental difference. For the same reason why we don't test all applications completely if a single line of code was changed in VCL or SFX2 I don't believe that we should declare all extensions incompatible automatically just because any implementation behind one of the APIs it uses might(!) have changed in a way that the extension can't cope with. This is exaggeration. If you change the behavior of a particular service in a way that you don't dare to name it compatible any longer: deprecate the old service name and create a new one! Services that are so implementation dependent maybe should get names like "my.service.name.version.2.3.1" anyway?! Extensions looking for the old service will automatically become incompatible then (provided that we get the "dynamical compatibility detection" I asked for). But why forcing all other extensions using completely unproblematic APIs to become incompatible automatically? That's again exaggeration. >> What we are doing now has worked for COM developers for a long time. It >> might not be the most comfortable thing for the developers but IMHO we >> should try to achieve comfort first for the users, developers second. >> >> About COM: you still can take StarOffice 3.0 from 1995 and embed a >> Writer 3.0 object into an Excel 2003 container. Of course nobody will do >> that for anything than testing and combining apps with more than 12 >> years difference in age is an exaggeration. But I hope you get the message. >> > Did you try? Yes. I found the same bugs in SO3.0 that I remember from the "good old days". :-) > IIRC, there _have_ been subtle differences that we'd have > to cater for, over the years. And I can counter with various other COM > examples, e.g. in the DirectX area, where interfaces stayed, for sure, > but ~nothing works unless one uses the very latest IDirect3DFoo21 > interface. So, I consider your example just that - an example that in > a defined area, a stable contract might be maintainable for an > extended period of time. But nobody would supposedly be able (nor > willing) to assert that for all of our 3000+ interfaces... IMHO that is not necessary. I claim that we have less bugs in OOo caused by changed behavior of API implementations than we have caused by unclear or misused "internal" (C++) APIs and "unexpected side effects" of their implementation. So I will give you a point when you show me that you test every line of code that depends on the code you have changed. If you don't do that I don't see why we should demand that for extensions using UNO APIs that are much less prone to such errors (I didn't say they are not prone to that at all!). So please let's stop that theoretical arguments and come to the real point: > we've already 7+ million LOC, and it's already a > heavy burden to maintain that. Compatibility is not a holy grail for > me - it's a tradeoff. And honestly, I'd currently rather spend > development resources on other stuff, than to workaround API > idiosyncrasies, or changing implementations to also handle > XWindow5... I don't question that. I understand that aiming for compatibility is hard and sometimes a PITA. What I miss is the user's perspective. Your arguments are very developer centric. There *is* a value in having extensions that work in many OOo versions even if their creators have stopped working on it. That's the reason why I want us to think about perceptible type incompatibilies that allow an extension to detect whether the types it uses are still compatible with the OOo release it is embedded into or not. I don't want to become all types incompatible in every major automatically so that no extension for e.g. OOo2.x will run in OOo3.0 even if some of them could. Let's make incompatibilites explicit, no matter if they are caused by API or behavioral changes. And allow extensions to deal with that but don't force them to become incompatible "just because". 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]
