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 introduced.

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
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com

Reply via email to