Hanno Schlichting wrote:
On Mon, Nov 30, 2009 at 1:21 PM, Martin Aspeli <optilude+lists@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