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.