Mathias Bauer <[EMAIL PROTECTED]> writes: > > But that's the only safe way to do this, for them. BTW, telling from > > past experience here: even if API stays compatible syntactically, > > there's absolutely no guarantee that the semantics haven't changed, > > and the extensions stops working anyway. > > Come on, then why create APIs at all? For the same reasons you could say > that no program is usable because it may have bugs. And indeed what you > describe is just this: a bug. > Hi Mathias,
no, it's not necessarily a bug. Compatibility circles around API contracts, which is (much) more than just method syntax. You can change function behaviour, even rightly so, e.g. to fix an outright bug, or when implementation differs from documented behaviour, and break an extension that relies on the old behaviour. And no, I even don't think this is bound to happen much less frequently than bugs caused by syntactical incompatibilities. > > I don't see much value in this UNO API compatibility discussion, > > unless we deal with this end-to-end. > I agree that we shouldn't rush things. I'm not convinced that we have > thought hard enough to get the flexibility we (the developers) want > without letting our users suffer from the consequences. > > If we are sure that we must nail extensions to major releases to get the > necessary flexibility so be it. But we should try hard to avoid that. > 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. > 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? 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... > So it *is* possible to keep compatibility without making an API > unusable. > Agreed. > Perhaps not always, but that has to be proven. > Unless you're not willing to take the implementation with you forever, this is easy to falsify. And that's the whole point Frank and others have been making: 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... > That's not exactly the Mozilla approach. Extensions usually are declared > as compatible for some releases, mostly until the next major (AFAIK the > project explicitly urges them not to declare their extension compatible > for the next major). This is wild guessing also. There's no QA involved > as you can't QA what has not been released. Only a few extensions are > marked comatible only for the current release. > OK, didn't know that. Regarding QA: that misses the point. You or the project can QA your extension against the release, and then flag it as compatible. Regardless of whether you're the maintainer or not. Cheers, -- Thorsten --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
