Hanno Schlichting wrote: > On Mon, Nov 30, 2009 at 1:21 PM, Martin Aspeli <optilude+li...@gmail.com> > wrote: >> Martijn Faassen wrote: >>> This implies we don't want to release zope.component 4.0 for a long time >>> yet. >> I think the answer should be "never". :) > > I think never is a rather long time. I'd suggest we think about these > changes more in the timeline of years. > > Looking at Python itself or Zope's own former deprecation policies, it > seems that policies where we deprecate / warn about API changes in one > release and change behavior it one or two releases after that seem to > work. They do rely on their being something like a coherent release of > some language / framework / toolkit though. And they rely on these > releases being made at an interval of at minimum a year or preferably > 18 months (as in Python's case). > > I think that once we get a ZTK 1.0 release out that promises to be > maintained for at least three years, we can start working on a ZTK 2.0 > which introduces deprecation warnings about the changed behavior and a > 3.0 that will change the default. If released at an interval of 18 > months like Python, that puts these changes about 3 years into the > future with a lot of time in between to adjust. > > Given such an approach I think we can indeed change core API's in > backwards incompatible ways. Python itself does this all the time, > look at Exceptions as new-style classes, new language keywords like > "with" or the massive amount of changes in Python 3. > > But if we treat zope.component / zope.interface just as two packages > of their own, I'd agree that we don't have any way to provide > reasonable backwards compatibility and ensure that some packages won't > use these straight away. The whole point of the toolkit is to ensure > we have a large number of packages that are compatible and tested with > each other.
I agree with your argument in general terms, but I think breaking this kind of thing is something we should *never* do lightly. It will always cause pain for a lot of people, not at least extra work to change a lot of code. If there's a good reason, we can sometimes do this on the type of basis you're suggesting. I don't consider a desire for the "perfect API" to be such a good reason. The alternatives that are (virtually) backwards compatible are not so bad that the marginal improvement of *args instead of taking a tuple (for example) are worth it. IMHO. ;-) I'm being rather forceful here, but I think it's an important point. If something is really broken or has dangerous side effects, we have a case for breaking backwards compatibility. If we just think it'd be a bit prettier to have it another way, then we don't. Living by past decisions is a part of being good software engineers, and the kind of thing that your customers actually love you for. Martin P.S. I don't agree with Python 3(000) either, but I've kept my mouth shut about that one. I would point out, though, that Python 3 doesn't have a stellar uptake at the moment. -- Author of `Professional Plone Development`, a book for developers who want to work with Plone. See http://martinaspeli.net/plone-book _______________________________________________ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )