Frank Schönheit - Sun Microsystems Germany wrote: > Hi Mathias, > >>> If major releases happen every 3 years, then allowing API changes only on a >>> mayor release does not make much sense to me. >> >> That depends from where you look at it. We always must consider that API >> users expect API stability, so we need to find a good compromise. >> Changing APIs every 6 months definitely isn't one. >> >> I think that for now aiming for 4.0 as the first release that allows for >> incompatible API changes is reasonable and I see this as a good >> opportunity to get the most annoying things fixed. So perhaps the >> "pressure" to have more fixes only a few months later shouldn't be too >> high and for now I would like to plan for 5.0 as the next release for >> more changes. > > I'd expect a timing problem then. If you need a precision landing for > your API change, then chances are good you will miss it - and then > you'll have to wait for another 3 years (which effectively means your > CWS will rot over that time). > > For a very good reason, we have a train model - "integrate what's done, > not more, not less" - for all other code changes. The lesson we learned > for features is that precision landings - "I want to have that finished > for release x.y" - are doomed to fail too often. Why should this be > different for API changes?
I don't buy that. If something is really important, I know that I have to get it ready in time and the available time is sufficient, I can start early enough. You are right, we won't be able to have exact timings for everything we do, but it should be doable to get some of the things (preferably the important ones ;-)) ready in a multi year planning. 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. 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. 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. 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. 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 "nospamfor...@gmx.de". I use it for the OOo lists and only rarely read other mails sent to it. --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@api.openoffice.org For additional commands, e-mail: dev-h...@api.openoffice.org
