On May 30, 2007, at 11:12 AM, Benji York wrote:
Jim Fulton wrote:
- IMO, backward incompatibility, and therefore, deprecation, is
no- longer an option.
While I don't disagree, I would like to brainstorm approaches to
handling non-backward-compatibility. One approach that's been
proposed is that when you have a package z3c.foo and you need to
make a backward-incompatible change you'd create, essentially, a
new package z3c.foo2. I like the simplicity of that, but it does
offend my sense of aesthetics a bit.
Another option would be that the major version number indicates
incompatibility. Therefore, z3c.foo 1.x would be incompatible with
any 2.y. One downside to that is that I don't think setup_tools
handles version numbers that way, so would be glad to provide a 2.0
version if you're not careful enough to say version < 2.0 when 2.0
doesn't yet exist, messing up your dependencies when 2.0 is
It's actually worse than that. <2.0 would admit 2.0a1. :) You'd
probably need something like < 1.99.
Even if developers remembered, it would be icky to have to spell out
something like >=3.4 <=3.99 on everwhere.
Using foo2 essentially embeds the major version in the package name,
which doesn't seem so bad to me.
Maybe there is some kind of dependency syntax that reads well that
means "I want this major version". Can you think of a syntax that is
actually nicer than foo2?
Jim Fulton mailto:[EMAIL PROTECTED] Python
CTO (540) 361-1714
Zope Corporation http://www.zope.com http://www.zope.org
Zope3-dev mailing list