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:


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 Fulton                      mailto:[EMAIL PROTECTED]                Python 
CTO                             (540) 361-1714                  
Zope Corporation        http://www.zope.com             http://www.zope.org

Zope3-dev mailing list
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com

Reply via email to