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

[Tarek Ziadé]

On Thu, Jun 11, 2009 at 8:05 PM, Trent Mick<trentm at gmail.com> wrote:
> 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.

Me too, dev version have to be included in the comparison tool.

>
> 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

What would be the difference then with the initial proposal ? You
would end up merging the "short" version
with the dev field to be able to sort different versions of the same
distribution.

If we have dev versions, we have to include them in the scheme

Tarek