[Distutils] recollections of Pycon distutils versioning discussion (part 1)

[Trent Mick]

>> An example of where more N's is useful is for a Python module that wraps
>> a third-party library. Say that library ("libfoo") version is 2.5.2, a
>> reasonable version for "python-libfoo" might be "2.5.2.1.0" where the
>> first three bits track the "libfoo" version.
>
> Purely theoretical example, I assume? I doubt I'd do this, but again,
> who cares? No conceptual cost.
>

Something similar I do for my "python-markdown2" module:
http://code.google.com/p/python-markdown2/source/browse/trunk/lib/markdown2.py#47



>>  N.N[.N]*[(abc)N[.N]*]
>>
>> ...
>
> -1
>
> 29/4975 is hardly anything, and I don't believe this should be defined
> on a "someone uses it so we should allow it" basis.
>
> If someone supports this, they should be presenting a good use case,
> with an explanation of why it is of value *to the end user* (ie, not
> just to the project developers).

Yes, I'd like to send a separate email to this list (perhaps to
python-list) that asks if anyone can pipe in with a good use
case/justification for this.

Anyway, in this email I'm just trying to put down my current
understanding of the proposal and the debate.

> Note: there's an assumption implicit in this that a "version" is
> something attached to a release - I have little sympathy with the idea
> that every single Subversion revision (or Mercurial changeset, or
> whatever) should have a unique "version" number. Unreleased versions
> should be identified differently (and nobody should be specifying
> dependencies on unreleased versions, before anybody suggests that!)

Ah... I'll get into that with the ".dev" stuff. :) Hopefully tonight.


Trent

-- 
Trent Mick
trentm at gmail.com