RFC: versioning proposal Re: [Zope3-dev] Specifying upper limits in dependencies

Bernd Dorn bernd.dorn at lovelysystems.com
Tue Jul 3 03:34:39 EDT 2007


On 02.07.2007, at 20:54, Jim Fulton wrote:

> See me response to Gary's note.
>
> Here's what I propose:
>
> 1. We adopt the policy that a distribution's version number must be  
> of less or equal maturity than all of it's dependencies, where  
> maturity is based on it's position in the release cycle.  dev is  
> less mature than alpha is less mature than beta is less mature than  
> release candidate is less mature than final.  So, for example, dev  
> release of zope.app.keyreference can depend on a dev release of  
> ZODB3, but an alpha release of zope.app.keyreference cannot.  
> Initially, this will be a convention. Eventually, I'll add a  
> feature to buildout to warn when this policy is violated.

+1

+10 to the policy violation warning

>
> 2. We approach the distutils sig with a feature request for an  
> option to prefer final versions, so that, if we specify the new  
> option, we always get the newest final version that satisfies a  
> requirement, if there is one.  I suggest that this be --prefer- 
> final. Anyone want to volunteer to bring this up there? :)  I don't  
> think we'll see this feature any time soon.
>
> 3. I add a prefer-final option to buildout to prefer final  
> versions. I think I can do this in the next week.

what about having some kind of '--min-maturity=beta' where the  
options are 'dev', 'a', 'b', 'c', 'final' or so

i don't know the exact syntax, but we have to take care of the right  
version syntax, because it seems that there is no policy that defines  
how  maturity levels are defined

e.g: x.x.xdev x.x.xax x.x.xbx x.x.xcx

we have some packages around that have x.x.x.dev x.x.x-dev and i  
think they are considered newer than x.x.xa1


>
> Thoughts?
>
> Jim
>
> On Jun 27, 2007, at 10:01 AM, Christian Theune wrote:
>
>> Hi,
>>
>> the recent introduction of zope.app.keyreference-3.5dev with it's
>> dependency on ZODB 3.9 brought some issues for me as I get  
>> conflicts in
>> various buildouts (e.g. z3c.zalchemy).
>>
>> In my example, z3c.zalchemy doesn't care about which version of
>> zope.app.keyreference it gets, as even the newer one won't affect us.
>>
>> I'd like to re-visit the discussion about "stable package  
>> versions" and
>> how to approach the distutils list to get what we want.
>>
>> Currently I resolve this issue by putting a specific version in my
>> project's buildout and leave the package (e.g. z3c.zalchemy) alone.
>>
>> I'm not sure whether this is the strategy we should use. Should
>> z3c.zalchemy say: I'm good with zope.app.keyreference==3.4 (with our
>> proposed syntax, or <3.5dev with the current syntax)?
>>
>> I'd like to see some consensus on how we handle those ...
>>
>> Christian
>>
>> _______________________________________________
>> Zope3-dev mailing list
>> Zope3-dev at zope.org
>> Unsub: http://mail.zope.org/mailman/options/zope3-dev/jim%40zope.com
>>
>
> --
> 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
>
>
>
> _______________________________________________
> Zope3-dev mailing list
> Zope3-dev at zope.org
> Unsub: http://mail.zope.org/mailman/options/zope3-dev/bernd.dorn% 
> 40lovelysystems.com
>



More information about the Zope3-dev mailing list