-----BEGIN PGP SIGNED MESSAGE----- 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. +1 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 clearly. Juergen -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCgAGBQJRGOKoAAoJEM/u8xZRtf3oGEMP/1trm7GtR3wwvIlOsuzuxSdU a1nSXZEgGZSkn2l1e9dSLi6B6pDkMiq4Em7lLaMKJku0A+52yzS8kVDGFRaVJesW RhzzI2cNqVvVRA+A97q97Jf2zr5gezsKSRYaWvXEyDAHkpc2Bg/t0Yvo4lwv5be1 GzRn9S9jVHLoGwjWy8FKO0WPi6DjlFplFn6+tFhhb4y5XP52jZo/B8DEKoMrM0VK 4bd7i2D2rtUKAOJWjhBgvp/kBvFMNQpXOlbcMqzz4jJyWChfIynvNydM3CiU3fnk kQuAs0uJruAuyCrr25FcQVHt9CSvWonjK78+pn4ATqxz5Q8SazRBcFfyeyu0S2Ku UCOXTET452kIyehsXtmaPl+Sv32msusXRGjJeHGnB+xIwNOyN0riek1R41ZtmqzQ zFV33Q7SlFyi6S7bzYHoHHGarijKhBOC3XDVeZDfDPSHAym03U3bMYqW4BCBaOTH 69lPFtjeaxjSk+xW3aOdKHasoMIv1v713sjZ1ZaeOo0kJhOa1KMQWSlr9AioTNwA Zi/QBLliRUNBfUuwoI0kAgf2eyGCBFYPku081mY5Qr5iEIAe2i9WKRoKNdjptX6w D5qOrIyEwY1btgfiKA381jtvdhGBvRWR/agoAKyd5Ov68J6zcAGmA8rOZynZ6pqo 2M+YSVRi5gIaBp3h94K4 =xV0F -----END PGP SIGNATURE-----
