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

Trent Mick trentm at gmail.com
Thu Jun 4 19:44:27 CEST 2009


2009/6/4 P.J. Eby <pje at 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 at gmail.com


More information about the Distutils-SIG mailing list