Hi Thorsten,
thanks for bringing this up. My plan was to come with a more conrete
proposal in the near future. But anyway now it is on the table again and
we should start to find a satisfying solution.
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. 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.
I don't know what your current type problem is but i am sure we can
really fast solve it without introducing such a list.
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.
Juergen
Thorsten Behrens wrote:
$subject has been discussed on and off for quite some time - as of
now, the law is "you must not change published (UNO) API". I'd like
to challenge this very rule, since (as all absolute rules) it's
silly in practice & hinders cleaning up cruft, of which there's
abundant in OOo.
To spark some heated debate, I've filed a patch issue that adds a
whitelist to offapi's type verification -
http://www.openoffice.org/issues/show_bug.cgi?id=91943 ;-)
Would love to hear your thoughts, and, as Frank proposed somewhere
else, we'd probably need some rules of what should be changed (and
what not).
Cheers,
-- Thorsten
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
