On Tue, Jul 22, 2008 at 10:46:58AM +0200, Juergen Schmidt wrote:
> By the way i set your patch to invalid because i think such a whitelist
> is the wrong mechanism. We already have the possibility to make
> incompatible changes at the reference rdb but it is not publicly
> documented and should be done explicitly. We use it for example to
> correct spelling errors, missing documented properties etc.
>
Hi Jürgen,
Issue reopened - then please let's discuss this other solution,
preferrably in the issue.
> Anyway the mechanism should be handled carefully.
>
> Don't misunderstand me i am not against API changes in general. I would
> really love to see some steps in the right direction but not simply by
> introducing a whitelist without a detailed definition what can be
> changed. And of course i would keep the current mechanism to explicitly
> change the reference rdb.
>
Understood - but I'm not happy with mixing this technical question
with the general problem of policy (either way, you would surely
watch commits to the whatever-it-is mechanism and object changes
that violate the to-be-defined policy).
> I think it is time to relax the incompatiblity statement but with some
> well defined rules (TBD). It is too important from my point of view and
> all changes should be well documented and if necessary a migration path
> should be provided as well.
>
Definitely. I guess there are (at least) the following cases:
1. unused API, or API that crashed OOo, or that was simply ignored
when calling the OOo implementation
2. syntactic changes, e.g. renaming, that will only cause
recompilation to break, but no existing client (maybe only for a
defined subset of frequently used implementation languages)
3. removal/renaming of seldomly used, or long-time deprecated API
4. removal/renaming of often used API
I'd say that 1. and 2. could be unanimously agreed upon, 3. needs
some careful consideration, e.g. publicly on this list, and a
migration path, and 4. should maybe just be left alone. ;-)
What do you think?
-- Thorsten
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
