Frank Schönheit - Sun Microsystems Germany wrote: >> Most of the changes you have in mind now are related to old existing >> APIs. So now you have many months to plan which APIs to change in 4.0 >> and calculate the effort. This should allow you to schedule the changes >> for the next major release. Planning for 4.0 means that you will have a >> time frame of at least 6 months for your "ready" date. So you can plan >> to have the changes ready half a year before the major release >> (immediately after branch-off date for the last 3.x version) and >> calculate the necessary starting dates accordingly. You still have >> several months leeway. Sounds doable to me. > > To me it doesn't, simply from the experience: Plannings *that* much in > the future tend to become overruled by unexpected events. Again, we have > a train model for code changes because we learned that often enough, > long-term planning simply doesn't work. I still think the same holds for > API changes.
This is a non-argument. Basically you are saying: I want to do it now because I think it won't be important enough to do it in a year. Sounds strange to me. I think API changes need a roadmap and a plan. And of course I assume that this plan is somehow incorporated into the general OOo roadmap. Otherwise it doesn't make sense to do it at all. So count me in when it comes to fight for the importance of API changes (in general - of course in detail it always depends on the particular case). >> Really, we shouldn't overburden our API "customers". We couldn't do any >> incompatible changes for now many years and last time I checked the >> project is still alive. So it should be OK for now to restrict >> incompatible changes to major releases. > > What's your definition of "incompatible" here? I think I have done that already: everything that causes code changes or recompilations. > Speaking strictly, the "old style" changes we already agreed upon are > incompatible, too. Would be a nonsensical definition, sure. I hoped that I differentiated that already in my last mail. Sorry if that wasn't clear enough. We are doing such changes even now where "real incompatible changes" aren't allowed (just seen it a few hours ago). These case are not interesting for our discussion at all as they just document the status quo anyway and don't break code, neither in source nor in binary form. > But is adding an exception specification to a method incompatible? Yes. I think we can make a deal if that fixes code that otherwise would crash or not work at all. > Is adding a method to a non/published interface incompatible? For published interfaces it's of course incompatible. > Is changing a parameter/return type of a method from XFoo to some new XBar > derived > from XFoo incompatible? Changing the parameter is of course incompatible; whether changing the return value is incompatible in a "practical sense" is an intersting question. It could work at least in C++, C# and Python (in Basic anyway). I don't know how it works in our Java Binding. > Is renaming an (most probably) unused method/interface incompatible? Depends on how much you believe in your skill to estimate the probability. :-) OK, seriously: it isn't. And in most cases I fail to see why such a change is necessary in a minor release. > Is merging the unpublished > XDialogProvider2 into the unpublished XDialogProvider incompatible? It's not only incompatible, it's forbidden. Otherwise the keyword "published" becomes useless. > Is cleaning up Ariel's menu interface mess in awt incompatible? I don't know what he did, but "cleaning up a mess" sounds incompatible by default. :-) These are a lot of interesting questions, but IMHO it doesn't matter what is "incompatible" or not, my concern is that making incompatible changes (whatever we define this) should not happen between major releases. This is not a technical decision, it's a matter of creating trust, more a symbolic act. > I think we need much more fine grained rules than allowing changes for > .0 releases only, since there's more than black and white. Since > creating all those rules here and now is illusionary, too, all I ask for > is being open-minded for more frequent changes, and discussing those > changes on a per-case basis. That will happen anyway. But I have problems to imagine API changes that are so urgent that they can't wait for a full release cycle. Beware: I'm talking about the time past 4.0, so there's a lot of time to prepare for fixing the most annoying cases (that we nevertheless survived for several years now) until then. I don't believe that we can't fix at least those APIs that are causing you pain until then. >> I think that even the impression that our API wouldn't be reliable for >> more than 6 months would be bad for our project. Even if you and me know >> that allowing for API changes basically in every minor release won't >> lead to complete chaos, the impression can emerge that indeed this will >> happen. > > This is a matter of communication, to some extent at least. Changing > APIs without telling anybody, and without providing a migration path, > will lead to this impression. Clearly and early saying what has changed, > why it has changed, and how clients need to be adjusted, will relax > this, IMO. You still ignore the fact that people evaluate something before they invest into it. If the system looks as if it *might* require code fixing work every 6 months it becomes less compelling. Try to see it from the other side - which library would you choose: the one that guarantees to force you to change your code only once a few years or the one where the maintainers say "we can't guarantee that you don't need to change your code every 6 months; we try to avoid it, but it might happen"? We now live with some bad APIs for a lot of years. It didn't kill us and the problems in our code base are not primarily caused by bad UNO APIs. Nevertheless, some things are annoying and so we will fix them. We might not be able to fix all annoyances and we might add new ones. But why should additional 2 years with these remaining or new annoyances (that's roughly the time between a .1 release and the beta of the next .0 release) kill us? I fail to see so much urgency that it let's me accept the potential feeling of unease that giving up compatibility between masters can cause. >> So I opt for targeting only major releases for all API changes that will >> force either code changes or recompilations. API changes with only >> documentary character (like in old-style services) should be possible at >> every release (even 3.x). >> >> Every agreement can be reconsidered later, so this one also. But we >> don't need to do that before 4.0 has actually shipped. > > Let's remove the last sentence :) I don't understand why. I would like to see where we are when 4.0 is ready for Beta and if it really will contain so much "dark areas" that they need immediate fixing. For the time being let's agree to disagree. Ciao, Mathias -- Mathias Bauer (mba) - Project Lead OpenOffice.org Writer OpenOffice.org Engineering at Sun: http://blogs.sun.com/GullFOSS Please don't reply to "[email protected]". I use it for the OOo lists and only rarely read other mails sent to it. --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
