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
> 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
Zope-Dev maillist - Zope-Dev@zope.org
** No cross posts or HTML encoding! **
(Related lists -