2009/6/5 Tarek Ziadé
But I acknowledge that I have no personal requirement for any of this, so the only interest I have is an aesthetic one of *not* seeing overcomplicated, difficult to understand, specifications become part of the Python stdlib.
Well if the specification is difficult to understand or overcomplicated it'll fail for sure.
But so far, besides that very specific case for the post-release dev tag, I don't find it complicated at all. Another win I can see is that it will help developers use better versions numbers for their projects imho.
And yet, in spite of repeated requests for specific examples of projects using this post-dev stuff, which haven't been forthcoming, why is nobody saying "it's an unnecessary complication, we'll drop it"? OK, I'll say it: Having post and dev specifications is unnecessary. Please remove it from the spec. As an alternative, allow a trailing '-' followed by arbitrary alphanumeric (a-zA-Z0-9) data. If this is all numeric, sort as numbers, otherwise sort textually. Numeric vs non-numeric is sorted as text. That covers -vendorid (as used by such things as cygwin, RPMs, etc - 1.2.1-3) -revision (e.g. subversion revision numbers 1.2-32471) -changeset (e.g. DVCS changeset id 1.3-0c30df5c527b) ... and anything else people want to invent (dates, developer's age, ...) I repeat - I don't have any experience in this area. But surely the people who do should be able to explain to me *why* they need something more complex than this? (Note: I'm assuming that the point of setting a standard is that people move to it - arguments like "Project XXX uses version numbers like so" don't count unless there's a justification why switching version numbering format isn't an option when they are planning to switch version parsing code in the first place!) Or I'm completely confused. (But I don't seem to be the only one). Paul.