From 1d46b1c749a9486adad4afb729f1bf2e459a6dba Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Tarek=20Ziad=C3=A9?= Date: Thu, 10 Dec 2009 13:14:25 +0000 Subject: [PATCH] copy editing + more details (python-dev feedback) --- pep-0386.txt | 45 +++++++++++++++++++++++++++++---------------- 1 file changed, 29 insertions(+), 16 deletions(-) diff --git a/pep-0386.txt b/pep-0386.txt index 849e92c43..7afaa3169 100644 --- a/pep-0386.txt +++ b/pep-0386.txt @@ -18,7 +18,7 @@ This PEP proposes a new version comparison schema system in Distutils. Motivation ========== -In Python there are no real restriction yet on how a project should manage its +In Python there are no real restrictions yet on how a project should manage its versions, and how they should be incremented. Distutils provides a `version` distribution meta-data field but it is freeform and @@ -47,18 +47,18 @@ versions. That is why this PEP proposes, for the sake of interoperability, a standard schema to express version information and its comparison semantics. -Furthermore, this will make OS packagers work easier when repackaging standards -compliant distributions, as of now it can be difficult to decide how two +Furthermore, this will make OS packagers' work easier when repackaging standards +compliant distributions, because as of now it can be difficult to decide how two distribution versions compare. Requisites and current status ============================= -It is not in the scope of this PEP to provide a universal versioning schema intended -to support many or all existing versioning schemas. There will always be competing -grammars, either mandated by distro or project policies or by historical -reasons and we cannot expect that to change. +It is not in the scope of this PEP to provide a universal versioning schema +intended to support all or even most of existing versioning schemas. There +will always be competing grammars, either mandated by distro or project +policies or by historical reasons that we cannot expect to change. The proposed schema should be able to express the usual versioning semantics, so it's possible to parse any alternative versioning schema and transform it @@ -73,7 +73,7 @@ purity, sometimes. Projects have very different versioning needs, but the following are widely considered important semantics: -1. there should be possible to express more than one versioning level +1. it should be possible to express more than one versioning level (usually this is expressed as major and minor revision and, sometimes, also a micro revision). 2. most projects need special meaning versions for "pre-releases" (such as @@ -138,8 +138,8 @@ your project:: >>> v1 > v2 False -The problem with this is that while it allows expressing requisite any -nesting level it doesn't allow to express special meaning versions +The problem with this is that while it allows expressing any +nesting level it doesn't allow giving special meaning to versions (pre and post-releases as well as development versions), as expressed in requisites 2, 3 and 4. @@ -193,14 +193,15 @@ It adds pre-release versions, and some structure, but lacks a few semantic elements to make it usable, such as development releases or post-release tags, as expressed in requisites 3 and 4. -Also, notice that Distutils version classes are not really used in the community. +Also, note that Distutils version classes have beed present since years +but are not really used in the community. Setuptools ---------- Setuptools provides another version comparison tool [#setuptools-version]_ -which does not enforce any rule for the version, but try to provide a better +which does not enforce any rules for the version, but try to provide a better algorithm to convert the strings to sortable keys, with a ``parse_version`` function. @@ -262,7 +263,7 @@ useful versions, which makes it difficult for users to grok the versioning that a particular package was using and to provide tools on top of PyPI. Distutils classes are not really used in Python projects, but the -Setuptools function is quite spread because it's used by tools like +Setuptools function is quite widespread because it's used by tools like `easy_install` [#ezinstall]_, `pip` [#pip]_ or `zc.buildout` [#zc.buildout]_ to install dependencies of a given project. @@ -288,7 +289,19 @@ It's currently called `verlib` and a prototype lives at [#prototype]_. The pseudo-format supported is:: - N.N[.N]+[abc]N[.N]+[.postN+][.devN+] + N.N[.N]+[{abc}N[.N]+][.postN][.devN] + +The real regular expression is:: + + expr = r"""^ + (?P\d+\.\d+) # minimum 'N.N' + (?P(?:\.\d+)*) # any number of extra '.N' segments + (?: + (?P[abc]) # 'a'=alpha, 'b'=beta, 'c'=release candidate + (?P\d+(?:\.\d+)*) + )? + (?P(\.post(?P\d+))?(\.dev(?P\d+))?)? + $""" Some examples probably make it clearer:: @@ -310,13 +323,13 @@ Some examples probably make it clearer:: True The trailing ``.dev123`` is for pre-releases. The ``.post123`` is for -post-releases -- which apparently is used by a number of projects out there +post-releases -- which apparently are used by a number of projects out there (e.g. Twisted [#twisted]_). For example *after* a ``1.2.0`` release there might be a ``1.2.0-r678`` release. We used ``post`` instead of ``r`` because the ``r`` is ambiguous as to whether it indicates a pre- or post-release. Last, ``.post456.dev34`` indicates a dev marker for a post release, that sorts -before a ``.post345`` marker. This can be used to do development versions +before a ``.post456`` marker. This can be used to do development versions of post releases. ``verlib`` provides a ``RationalVersion`` class and a