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