On Jul 2, 2007, at 9:42 PM, Jim Fulton wrote:

Thanks for reply.  quick notes:

I think that in *technically* depending on a newer version introduces a backward incompatibility. (It's like strengthening a precondition of a method.) This is especially a problem if people are specifying upper limits for their requirements, which is only necessary if there backward incompatible changes. ZODB 3.9 won't be backward incompatible in any meaningful way.

ZODB 3.9, like 3.8 *is* backward incompatible because it drops features that we agreed, as a community, to drop. Arguably, ZODB 3.8 should have been ZODB 4 and ZODB 3.9 should be ZODB 5, but I don't think we want to do that.

So, let''s say, as a practical matter, that ZODB 3.9 is backward compatible with 3.8. We don't know that 3.9 is ready for use yet. It's possible that there have been bugs introduced in 3.9 (or soon will be) that will be discovered and fixed during the beta cycle. Many people rightly don't want to depend on 3.9 until it has been released in a final form.

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.

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?


- For this particular problem, I wish my ZODB changes could go into ZODB 3.8. As I mentioned in the commit message, the change includes one bug fix for a potentially serious problem that could cause data integrity issues;

This could go into 3.8.

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.

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

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

and one feature (conflict resolution now supports multi databases).

This is a bug fix and could go into 3.8.

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.

- Even if people agreed with me for the previous bullet, that doesn't make this kind of problem go away.

- 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


My current opinion is that version numbers are the best solution of a bad lot.

I think we really need a way to limit the algorithm for finding distributions to avoid immature (releases).

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.


Zope3-dev mailing list
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com

Reply via email to