On Jul 2, 2007, at 3:07 PM, Gary Poster wrote:
Bernd has suggested a policy that I think we should adopt, which is that a package's release status should be no higher than the status of it's dependencies. So, for example, if A depends on a dev version of B, then the version of A that has this dependency should be a dev version. A should not be able to go to alpha, or beta, or final without a corresponding advance of its dependency on B.

Unless I misunderstand, this is what I did, actually, and Bernd (and probably others) didn't like it. That is, I have a zope.org/ distributions release of zope.app.keyreference 3.5 dev and ZODB 3.9 dev, and I said that keyreference 3.5 depended on ZODB 3.9 dev.

Cool. I guess I missed that.


I like the proposal you and Benji came up with. In that case, would what I released (except that I used "-dev" rather than "dev") be correct?



one new feature (more informative PersisntentReferences) that supports an arguable zope.app.keyreference bugfix (conflict resolution breaks with persistent key references;

Can you remind me or point me at something that describes in more detail?

ZODB/ConflictResolution.txt line 226 ff.

I think the __cmp__ method is a bug fix. Would that be enough for zope.app.keyreference?


Does zope.app.keyreference work as well as it does now without this?

I haven't tested it, but yes, I believe it should.

Then if we back-ported the bug fixes, as I think we should, then zope.app.keyreference could depend on 3.8, or perhaps even 3.7.


Then I'd argue that the zope.app.keyreference change could go into 3.4.

Are we really talking about 3.4?

Yes, zope.app.keyreference. "Not breaking BTree conflict resolution" could be cast pretty easily as a bugfix.

I'm still not sure what this has to do with 3.4. :)


- Also for this particular problem, I suppose I could remove the dependency on ZODB 3.9 and add a test to show that it should still "work" (as well as it did before at least) with ZODB 3.8 persistent references. I'd really rather not, of course, but I can do it in the next week and a half. I guess it would still be "3.5" but it wouldn't depend on 3.9 (...except to actually have any improvements over 3.4!)

I think you should do this or make your version of zope.app.keyreference a dev version.

OK, I'll see what I can do

It sounds like it already is a dev version.


I just brainstormed this with Benji and we both think that it would be enough to have an option that says: "I prefer final versions" meaning that we always want the latest final version that satisfies our requirements, if there is one. Ideally, this would be a setuptools option, however, this would be a new feature and I don't think we'll see new setuptools features any time soon. I could add this as an option to buildout.

sounds good to me. Being able to override it for individual packages would be important for me.

You'd override it by specifying a needed dev version in a requirement.


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