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

Trent Mick trentm at gmail.com
Tue Jun 9 21:52:38 CEST 2009

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

>>  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 Mick
trentm at gmail.com

More information about the Distutils-SIG mailing list