2009/6/4 P.J. Eby <pje@telecommunity.com>

At 09:41 AM 6/4/2009 -0700, Trent Mick wrote:

...

Can people point to some examples of projects using post-release tags, and that would require the use of a "dev release of a post release"?

Any project that uses a post-release tag and has multiple developers or multiple commits required to create that post-release version, will need the dev tagging to distinguish installed/development versions from each other, even if these intermediate versions are never "released" to PyPI.  People working from checkouts will need them to keep their install/build tools happily humming along, able to tell which intermediate checkout version they're workign with and whether they are up-to-date.

Are there any such projects that people can point to? http://peak.telecommunity.com/DevCenter/setuptools says

A post-release tag is either a series of letters that are alphabetically greater than or equal to "final", or a dash (-). Post-release tags are generally used to separate patch numbers, port numbers, build numbers, revision numbers, or date stamps from the release number. For example, the version 2.4-r1263 might denote Subversion revision 1263 of a post-release patch of version 2.4. Or you might use 2.4-20051127 to denote a date-stamped post-release.

I wonder if there is too much potential for confusion here. The "2.4-r1263" example: I would interpret that to be a *pre*-release of version 2.4. However verlib.py's "suggest_rational_version" does suggest "2.4.post1263" for this. I guess that is fine, because the RationalVersion spelling (with the explicit "post") is more self-explanatory. 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". 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)? Trent -- Trent Mick trentm@gmail.com