Re: RFC: versioning proposal Re: [Zope3-dev] Specifying upper limits in dependencies
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@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/jim%40zope.com -- Jim Fulton mailto:[EMAIL PROTECTED]Python Powered! CTO (540) 361-1714 http://www.python.org Zope Corporationhttp://www.zope.com http://www.zope.org ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/bernd.dorn% 40lovelysystems.com ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: RFC: versioning proposal Re: [Zope3-dev] Specifying upper limits in dependencies
On Jul 3, 2007, at 3:34 AM, Bernd Dorn wrote: ... what about having some kind of '--min-maturity=beta' where the options are 'dev', 'a', 'b', 'c', 'final' or so Can you think of a use case in which you'd want that? I feared we might want something like this, which is why I brainstormed this with Benji a bit and couldn't really think of a case. I can think of cases where I'd want specific non-final versions of specific packages, but that is handled by specifying requirements for those packages. 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 This is a case where setuptools is more powerful than necessary. For example, it would let you create something like: 1.0a1b2dev which is just silly. In any case, I'd call the above a dev release. I haven't worked out the details yet, but I assume that I'll be able to scan a parsed version and pick the lowest modifier. 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 a .dev release is older than a .a1 release (or a1). The '-' makes a post-release tag, so x.x.x-dev is later than x.x.xa1. Jim -- Jim Fulton mailto:[EMAIL PROTECTED]Python Powered! CTO (540) 361-1714 http://www.python.org Zope Corporationhttp://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
Re: RFC: versioning proposal Re: [Zope3-dev] Specifying upper limits in dependencies
Hi,
Am Dienstag, den 03.07.2007, 06:19 -0400 schrieb Jim Fulton:
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
a .dev release is older than a .a1 release (or a1). The '-' makes a
post-release tag, so x.x.x-dev is later than x.x.xa1.
That's what the spec says. However, that's not how setuptools worked for
me a week ago and is now.
'1.0-dev' is considered earlier than '1.0' as is '1.0dev':
from pkg_resources import parse_version
parse_version('1.0dev')
('0001', '*@', '*final')
parse_version('1.0-dev')
('0001', '*@', '*final')
parse_version('1.0-r123')
('0001', '*final-', '*r', '0123', '*final')
parse_version('1.0r123')
('0001', '*r', '0123', '*final')
parse_version('1.0a1')
('0001', '*a', '0001', '*final')
parse_version('1.0-a1')
('0001', '*a', '0001', '*final')
parse_version('1.0')
('0001', '*final')
Christian
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: RFC: versioning proposal Re: [Zope3-dev] Specifying upper limits in dependencies
Hm, you're right. Note:
from pkg_resources import *
parse_version('1.0') parse_version('1.0-dev')
False
parse_version('1.0') parse_version('1.0-r10')
True
So dev gets special treatment. Wonderful. I guess that must be
intuitive.
Jim
On Jul 3, 2007, at 6:59 AM, Christian Theune wrote:
Hi,
Am Dienstag, den 03.07.2007, 06:19 -0400 schrieb Jim Fulton:
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
a .dev release is older than a .a1 release (or a1). The '-' makes a
post-release tag, so x.x.x-dev is later than x.x.xa1.
That's what the spec says. However, that's not how setuptools
worked for
me a week ago and is now.
'1.0-dev' is considered earlier than '1.0' as is '1.0dev':
from pkg_resources import parse_version
parse_version('1.0dev')
('0001', '*@', '*final')
parse_version('1.0-dev')
('0001', '*@', '*final')
parse_version('1.0-r123')
('0001', '*final-', '*r', '0123', '*final')
parse_version('1.0r123')
('0001', '*r', '0123', '*final')
parse_version('1.0a1')
('0001', '*a', '0001', '*final')
parse_version('1.0-a1')
('0001', '*a', '0001', '*final')
parse_version('1.0')
('0001', '*final')
Christian
--
Jim Fulton mailto:[EMAIL PROTECTED]Python
Powered!
CTO (540) 361-1714
http://www.python.org
Zope Corporationhttp://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
RFC: versioning proposal Re: [Zope3-dev] Specifying upper limits in dependencies
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. 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. 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@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/jim%40zope.com -- Jim Fulton mailto:[EMAIL PROTECTED]Python Powered! CTO (540) 361-1714 http://www.python.org Zope Corporationhttp://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
Re: RFC: versioning proposal Re: [Zope3-dev] Specifying upper limits in dependencies
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 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. +1 3. I add a prefer-final option to buildout to prefer final versions. I think I can do this in the next week. +1 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@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/jim%40zope.com -- Jim Fulton mailto:[EMAIL PROTECTED]Python Powered! CTO (540) 361-1714 http://www.python.org Zope Corporationhttp://www.zope.com http://www.zope.org ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/batlogg.lists% 40lovelysystems.com -- Special cases aren't special enough to break the rules. -- The Zen of Python, by Tim Peters Jodok Batlogg, Lovely Systems Schmelzhütterstraße 26a, 6850 Dornbirn, Austria phone: +43 5572 908060, fax: +43 5572 908060-77 smime.p7s Description: S/MIME cryptographic signature ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
