Hi Mathias, >> 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.
with that, you didn't address my scenario where an API change is induced by the developer's own pain in using the API, and where referring it to "later" effectively becomes "never". Okay, we might have different opinions on how realistic that is - actually, nearly all of my wishes for API changes result from my own pain using the old API. Be it. > 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. > 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? Speaking strictly, the "old style" changes we already agreed upon are incompatible, too. Would be a nonsensical definition, sure. But is adding an exception specification to a method incompatible? Is adding a method to a non/published interface incompatible? Is changing a parameter/return type of a method from XFoo to some new XBar derived from XFoo incompatible? Is renaming an (most probably) unused method/interface incompatible? Is merging the unpublished XDialogProvider2 into the unpublished XDialogProvider incompatible? Is cleaning up Ariel's menu interface mess in awt incompatible? 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. > 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. > 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 :) Ciao Frank -- - Frank Schönheit, Software Engineer frank.schoenh...@sun.com - - Sun Microsystems http://www.sun.com/staroffice - - OpenOffice.org Base http://dba.openoffice.org - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@api.openoffice.org For additional commands, e-mail: dev-h...@api.openoffice.org
