>> 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 tre...@gmail.com _______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
