On Thu, Feb 7, 2013 at 4:17 AM,
Mine wasn't an objection: it was a plain refusal.
Your preferred lexicographically sorted scheme is completely compliant with both PEP 386 and PEP 426. It merely expects users to write their requirements as ">= 1.1, < 1.1.90" if they don't want to accidentally download pre-releases. By contrast, starting with PEP 426, alphanumeric pre-releases will be excluded by default (while still allowing users to explicitly request them when necessary). I'll be updating the PEP to include some simpler examples of compliant versioning schemes projects may actually want to use, as well as including more rationale for the complexity of the overall scheme (still not as much as PEP 386, but at least some). The sole current example, which includes *every* feature of the version scheme in a single list is intended as a stress test for metadata processors, rather than as any kind of guide to possible versioning schemes. I now realise this is potentially confusing for users looking for guidance on the kinds of versioning schemes they can use while still remaining within the format defined by the PEP. The one *actual* change I will be making to the version scheme in the next draft is to allow Fedora/Firefox/Chrome style version numbering where there are only major releases, with no minor marker. Since the version scheme also constrains what is permitted inside version specifiers, this will also serve to permit things like "Requires-Python: 2" as a shorthand for "Requires-Python: >= 2.0, < 3" (and similar in Requires-Dist and Setup-Requires-Dist for other projects where major releases may contain backwards incompatible changes, and thus cross-version compatibility should be explicitly indicated with more permissive specifiers like ">=2.6, >=3.2, <4") Regards, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia