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

[Jim Fulton]

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:jim at zope.com		Python Powered!
CTO 				(540) 361-1714			http://www.python.org
Zope Corporation	http://www.zope.com		http://www.zope.org