[Zope-dev] implementing zope.component 4.0

[Martin Aspeli]

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