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