[Distutils] post-release tags and RationalVersion (Was: PEP 345, PEP 376, PEP 386)

[P.J. Eby]

At 10:44 AM 6/4/2009 -0700, Trent Mick wrote:
>Back to a "dev version of a post release", given the only examples I've seen:
>- "2.4-r1263": given that the post-release is using the Subversion
>revision number here, how can a "dev version" if this be meaningful?
>- "2.4-20051127": A potential alternative to this would be to just
>call it "2.4.20051127" (i.e. not a "post-release of 20051127" but a
>"patch-level version of 20051127".

In setuptools' case, the original intent was to be compatible with 
projects that do have things like '2.4-1' - e.g., because they're a 
wrapper of a library whose version is 2.4, and the wrapper is the 
first version of that.  If the library then releases a '2.4.1', the 
wrapper for that is then '2.4.1-1'.  However, some projects (see 
Jean-Paul Calderone's recent questions here) have things like '2.4+1' 
as a patch level.

Anyway, the point is that you can have a development of a patch 
level, and patch levels are considered distinct from dotted levels.


>I guess where I'm going is: given that RationalVersion requires
>post-release values to be numeric, it seems that a valid solution is
>to just have an additional version element. So instead of "2.4-r123"
>you use "2.4.123". Instead of "1.0c1-r456" you use "1.0c1.456".
>
>Is there any usage of a post-release that doesn't fit in this scheme?
>
>Is there a potential practical problem with getting users to switch to
>that? E.g. Perhaps something with the setup.cfg config variables that
>setuptools' versioning supports (I'm not that familiar with them)?

I think we're going to have to stage the implementation on the 
setuptools side, first by switching tagging functions to a 
plugin-based operation, and second to provide optional version 
conversion/rationalization.

I personally don't think it will ever make sense to *require* version 
rationalization, since Python is certainly used for private projects 
and companies may have their own numbering schemes.  At most, we can 
warn about versions being potentially not-parseable or being not 
suitable for PyPI distribution if at some point PyPI can reasonably 
become strict about the matter.