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 Corporation http://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
