Mathias Bauer <[EMAIL PROTECTED]> writes: > 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. > Sure it is. That unexpected side effect usually gets caught during release QA. That's been my point all the time: the mismatch between that and our internal (c++) APIs, the lessons we've learned there, and the amount of testing we do for releases - and the imo false hope that those experience somehow magically doesn't apply to extensions.
> 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. > No more exaggeration than banning syntactical API changes, hoping that this will ensure eternal working of arbitrary extensions. > But why forcing all other extensions using completely unproblematic > APIs to become incompatible automatically? That's again > exaggeration. > Yeah. But turning this around, this is how we currently handle existing API: banning completely unproblematic changes to supposedly very infrequently used API, in the hope that this will keep extensions runnable. You could of course counter that nobody knows what's unused/seldom used - but then again, that argument cuts both ways, since your categorization of "unproblematic" is also only an assumption. > 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. > Certainly - we unfortunately don't use UNO as much as plain C++ internally. > 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!). > Again: we _do_ run tests over the whole office for a release. Plenty. With the current proposal for extensions, we run _no_ tests at all for them. We just assume that they'll work. > 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. > Sure. All of 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". > Yes, I agree. That's what the thread in [EMAIL PROTECTED] I was referring to earlier is about. I happily notice that this opens the door a bit for binning parts of published UNO API for the first time ever. Cheers, -- Thorsten --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
