Martin Aspeli wrote:
> Martijn Faassen wrote:
>> IFoo(one, two)
> Please note that this will break an incredible amount of code "in the
> wild". A good number of my packages do something like this:
> foo = IFoo(context, None)
> if foo is None:
Yes, that this would break a lot of code is well known
[backwards compatibility discussion]
> Because we now have so many packages and things are being released as
> eggs and mixed up in various platforms and projects, this type of
> "gross" backwards incompatibility is virtually impossible to manage.
> To take an example, I'm sure Stefan & co will release z3c.form 3
> depending on zope.component 4 before long, and we'll want to use that in
> Plone. Except we can't, because even if z3c.form never uses the
> IFoo(one, two) syntax, everything in Plone that uses IFoo(context, None)
> would suddenly break.
That's why I think it's important to have a:
* a zope.component 3.x that supports both patterns
* a per-module way to indicate whether the new API should be used.
We'd commit to maintaining zope.component 3.x in parallel with
zope.component 4.0. We'd recommend to people *not* to require
zope.component 4.0 for a period, or perhaps we'd even not release it for
quite a period.
The documentation issue is a more severe one.
> I think Jim said once, "we can't ever have backwards incompatibility".
> Other "serious" platforms like Java or .NET have a similar stance. They
> deprecate liberally, but never actually break anything.
> (Remember java.util.Data and java.util.Calendar?)
No, I don't remember. :)
> We may never be able to do that
> completely, and we may *want* to root out some dodgy bits of code that
> few people use. But breaking something so fundamental and so commonly
> used would be criminal, in my book.
Taken into consideration.
>> I think it's important not to do a "big bang" upgrade but instead allow
>> people to upgrade bit by bit. It should be possible to compose an
>> application that mixes code that expects the old semantics with code
>> that expects the new semantics. A bit by bit upgrade I think would
>> ideally be on a per-module basis. I think it's important to make sure we
>> can support such an upgrade *before* we release any of this.
> I'm not sure that's going to be possible. As soon as someone does
> zope.component >= 4.0 in their setup.py, you're screwed.
This implies we don't want to release zope.component 4.0 for a long time
Zope-Dev maillist - Zope-Dev@zope.org
** No cross posts or HTML encoding! **
(Related lists -