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? That is, if I have some larger change which we all agreed upon is necessary and reasonable to do, then I could start *now*, and as soon as it's finished, it would be integrated. If I need to wait for a 4.0 release, whose timeline is not remotely known currently, then I will defer the work. For various reasons, chances are good that it is actually deferred to "never" then: I might have other urgent things to do when time is ready for 4.0. Or, my personal interest in this change might be a client implementation of my own, causing pain in using the old API. By deferring the implementation of the new API, I will wade through the pain of using the old API. And later on, I will not have any good arguments (for my manager, and for myself) to embark on the project, again. (Until another painful client implementation, which sadly will be 1 month after 4.0 is out.) So, I still think we should be more open to API changes between major releases, if we seriously want them to happen. (And no, they're not an end it themselves.) Ciao Frank -- - Frank Schönheit, Software Engineer [email protected] - - Sun Microsystems http://www.sun.com/staroffice - - OpenOffice.org Base http://dba.openoffice.org - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
