[Distutils] version scheme: a case for dropping ".devNNN" and ".postNNN"

[Trent Mick]

On Thu, Jun 11, 2009 at 9:03 AM, Ian Bicking<ianb at colorstudy.com> wrote:
> On Thu, Jun 11, 2009 at 10:53 AM, P.J. Eby<pje at telecommunity.com> wrote:
>> For example, if I'm working on two projects that are distributed via SVN and
>> one depends on the other, if I update one, it may require an update of the
>> other; the failure of the .dev#### version requirement in the first one will
>> inform me of the need to "svn up" the second project and rerun "setup.py
>> develop" on it.
>>
>> This is a routine circumstance in at least my development cycle; I would
>> expect that it's the case in other open source development workflows as well
>> as proprietary ones.
>
> Agreed, I do this all the time.  Pylons dev versions also regularly
> rely on other packages with a dev version, and people regularly use
> these non-released versions, with dependencies detected and installed
> via dependency_links.

If there were a setup.py metadata field (called "dev_revision" or
"build_number" or something), separate from the "version" field, that
was used to hold the value for sorting/distinguishing unreleased
versions... could that work?

I.e. Have the shorter "N.N.N[(a|b|c)N]" scheme for "version" to be
used for "released" packages. And have a separate field (or fields)
for use in dependency handling of unreleased versions? Putting the two
together is resulting in package uploads to PyPI
(foo-1.2.3.dev-r456.tar.gz) that I think were never intended in the
design

A weird thing about defining a sort order for:

  1.2.3.dev-r450
  1.2.3          # this is the released version (svn rev was r454)
  1.2.3-r456

is that it is comparing apples and oranges. The "1.2.3" released
version *had* a VCS revision number (or release date, or "number of
patches").


Trent

-- 
Trent Mick
trentm at gmail.com