Hash: SHA512

On 2/11/13 12:24 PM, Ariel Constenla-Haile wrote:
> Hi,
> Sorry for the delay, I'm on vacations mode.
> On Mon, Feb 04, 2013 at 01:44:49PM +0100, Jrgen Schmidt wrote:
>> Hi Ariel,
>> after some talks about this topic at FOSDEM I was thinking about
>> it again. What do you think how much effort it would be to create
>> a new scheme for the new extended toolbars and keep the old one
>> at least for a while? I know it will be more work in the
>> underlying code but we should at least think about it or what do
>> you mean?
> I guess you are talking about leaving the "OfficeToolBar" as
> before:
> <set oor:name="OfficeToolBar" oor:node-type="ToolBarItems"> </set>
> and adding a new set:
> <set oor:name="SomeNewNameForExtensionToolbars"
> oor:node-type="ToolBar"> </set>
> I don't see the point in having two sets, it's just adding more 
> complexity and awfulness to the one already there.

I totally agree and you confirm my assumption.

> And compatibility is not an argument here: an extension that uses
> this configuration set is a code-extensions; an extension using
> simply toolbar merging might have no code in it, but extensions
> with own toolbars have code. Any extension having code, must be
> checked by the extension developer in order to adapt it to the
> incompatible API changes.
> For this particular subject of the incompatible change of schema I
> see two options:
> - leave the change as is
> - revert commit in revision 1429069 
> http://svn.apache.org/viewvc?view=revision&revision=1429069
> I'm fine with reverting it; if you think so, simply ask and Ill do
> it (side note: you knew it was an incompatible change 
> http://markmail.org/message/7qbzndiascunlx2i and gave the ok to
> commit it - at least Ii had inferred this from seeing my name in 
> http://markmail.org/message/fhsepy2a56yhubi2 ).

don't get me wrong I am still supporting this change 100%. I simply
wanted to make clear that we listening to raised concerns and think
about it at least. And I think that my opinion doesn't count more than
from anybody else ;-)

> Back to the subject of this thread, that really misses the point
> mixing the configuration schema change: the incompatible API
> changes are not arguable, this has been already discussed several
> years ago; it's not "there is a major version, so let's change the
> API in an incompatible way"; on the contrary, it is about API
> changes that have been on the queue for a long time, waiting for a
> major release.
> I will only put as example my first code contribution to
> OpenOffice.org: http://markmail.org/message/ntqgiwaclcuhuzfk
> It would be interesting that people read the whole thread 
> http://markmail.org/thread/vdoydqphpsyw2mw6 because the whole thing
> is turning now into some kind of dej¢-vu.
> This is a clear example of an incompatible API change that was
> known since the very first time it was developed, and that was
> waiting since 2008 for a major release; and the incompatible API
> change was applied in revision 1425458 
> http://svn.apache.org/viewvc?view=revision&revision=1425458 and is 
> tracked under bug 121542 
> https://issues.apache.org/ooo/show_bug.cgi?id=121542#c2
> This is a rather illustrative example of me "cleaning up my own
> mess" (http://markmail.org/message/m7wousc55loekdxa the whole
> thread is worth reading in order to avoid the waste of time of
> discussing already discussed things
> http://markmail.org/thread/tid7fj6mg5wxlz4b), but there are several
> other obvious examples; if we had the time and resources (code
> contributors), the whole API should be reviewed, going through 
> every idl file.

+100 'I am totally with you here

> And this incompatible API change isn't arguable, that is: it has
> already been discussed, I won't revert it, and won't accept anyone
> else reverting it, period.


In general I believe we must be able to change things to correct
design errors or simply to improve things. We have proven that we made
a lot of mistakes and still tried to keep API's compatible, we should
look forward and should allow to fix such problems with major
releases. Important is that we show and document the migration path


Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/


Reply via email to