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.
Thoughts? -- Benji York Senior Software Engineer Zope Corporation _______________________________________________ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
