[Zope3-dev] package branches

[Jim Fulton]

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:jim at zope.com		Python Powered!
CTO 				(540) 361-1714			http://www.python.org
Zope Corporation	http://www.zope.com		http://www.zope.org