3G Eden
RSS这个 PEP 的通过对 Python 项目的使用者和开发者都是一个好消息。
那么这个 PEP 和版本号有什么关系呢？答案是新增的 Require-Dist 属性里可以包含版本范围的信息（x项目以来y项目的版本不小于z）。而这个信息自然会应用到版本大小的比较。如果一个项目的版本格式是随机的，那 Python 项目的安装工具就无法识别 Require-Dist 里的版本范围，从而无法通过比较版本大小来安装项目的依赖包。所以作为一个 Python 开发者，如果想让自己的项目能在将来顺利安装，最好还是从今天开始使用规范的版本系统和格式。
怎样的版本格式才算规范呢？Python 核心已经通过 PEP386 为我们回答了这个问题。Python 在将来能原生识别和比较的版本应该具有以下格式:
N.N[.N]+[{a|b|c|rc}N[.N]+][.postN][.devN]
从左向右做一个简单的解释：
- "N.N": 版本号里唯一必备的部分，两个"N"分别代表了主版本和副版本号，绝大多数现存的工程里都包含该部分。
- "[.N]": 次要版本号，可以有零或多个。
- "{a|b|c|rc}": 阶段代号，a, b, c, rc分别代表alpha, beta, candidate 和 release candidate, 可选
- "N[.N]": 阶段版本号，如果提供，则至少有一位主版本号，后面可以加无限多位的副版本号。
- ".postN": 发行后更新版本号，可选。
- ".devN": 开发期间的发行版本号，可选。
不难看出这个格式其实是建立在大多数既存项目已经普遍应用的格式的基础之上的，这也是这个PEP的提出者的初衷：尽量保持与现状的兼容性。
下面举几个规范版本格式的例子：
- '1.2'
- '3.2.3.2c5.4.12' （3.2.3.2 的 candidate 阶段的 5.4.12 版本）
- '2.7.dev231' （2.7开发版231次发行）
- '1.0.1rc2.post2' （1.0.1 的 release candidate 第二发行版本）
符合规范的版本号即使格式不同也能相互进行比较，PEP386 里面给的例子能说明很多问题：
>>> from verlib import NormalizedVersion as V
>>> (V('1.0a1')
... < V('1.0a2.dev456')
... < V('1.0a2')
... < V('1.0a2.1.dev456')
... < V('1.0a2.1')
... < V('1.0b1.dev456')
... < V('1.0b2')
... < V('1.0b2.post345')
... < V('1.0c1.dev456')
... < V('1.0c1')
... < V('1.0.dev456')
... < V('1.0')
... < V('1.0.post456.dev34')
... < V('1.0.post456'))
True
结果非常的符合直觉。至少 DaNmarner 是这么觉得。
最后补充: 上面例子中的 verlib 还在开发阶段，代码在这里，它将成为未来的 distutils.version 模块。 PEP 386 是 Python 和 Ubuntu，Fedora 一起提出的。
你的 Python 项目有一个符合 PEP386 的版本吗？
本文最初发表于 DaNmarner的中文博客， 这里是原文连接。
时间:2010-07-19 16:35
来源:DaNmarner的中文博客
作者:DaNmarner的中文博客
原文链接
