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?
Yes
...
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
--
Jim Fulton mailto:[EMAIL PROTECTED] Python
Powered!
CTO (540) 361-1714
http://www.python.org
Zope Corporation http://www.zope.com http://www.zope.org
_______________________________________________
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
