I am close to accepting the latest draft of PEP 426 as v1.3 of the package metadata standard.
However, while I agree the current requirement that version numbers *must* be in PEP 386 format needs to be relaxed, I don't think the text as written quite achieves that. 1. The "Version" field description should refer to the "Version Specifiers" section rather than directly to PEP 386 2. The version format flexibility must also be addressed in the "Version Specifiers" section (it currently still mandates PEP 386) 3. There needs to be a mechanism to inform automated tools of the *right* version ordering to use, with PEP 386 being the default. 4. A new version numbering scheme shouldn't require a new metadata version As a simple proposal: a new "Version-Scheme" field, with currently supported values "setuptools" and "pep386", and a clause allowing future "pepXYZ" versioning schemes. The version scheme field then effectively defines how versions are sorted for ordered comparisons involving that distribution. (Sorry Daniel, I know it's annoying to have official acceptance of the changes you were originally interested in held up by an unrelated problem, but it makes sense to fix this now, rather than letting the ambiguity persist) I also noticed a couple of minor editing tweaks that are needed: Under the "Fields" heading: s/The fields may appear in any order within the file./The fields may appear in any order within the header section of the file./ Under "Requires-External": s/there's is/there is/ Regards, Nick. P.S. Today I learned that 'chili' is the US spelling of 'chilli' -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia _______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig