Python 项目版本格式

项目版本

PEP 440（ http://www.python.org/dev/peps/pep-0440/ ）针对所有的Python包引入了一种版本格式

PEP440中定义版本号应该遵从以下正则表达式的格式：

[N!]N(.N)*[{a|b|rc}N][.postN][.devN]

它允许类似1.2或1.2.3这样的格式，但需注意以下几点：

• 1.2等于1.2.0，1.3.4等于1.3.4.0，以此类推。
  
• 与N[.N]+相匹配的版本被认为是最终版本。
  
• 基于日期的版本（如2013.06.22）被认为是无效的。针对PEP440格式版本号设计的一些自动化工具，在检测到版本号大于或等于1980时就会抛出错误。
  
• 最终即将发布的组件也可以使用下面这种格式。
  

N[.N]+aN（如1.2a1）表示一个alpha版本，即此版本不稳定或缺少某些功能。

N[.N]+bN（如2.3.1b2）表示一个beta版本，即此版本功能已经完整，但可能仍有bug。

N[.N]+cN或N[.N]+rcN（如0.4rc1）表示候选版本（常缩写为RC），通常指除非有重大的bug，否则很可能成为产品的最终发行版本。尽管rc和c两个后缀含义相同，但如果二者同时使用，rc版本通常表示比c更新一点。

通常用到的还有以下这些后缀：

• .postN（如1.4.post2）表示一个后续版本。通常用来解决发行过程中的细小问题（如发行文档有错）。如果发行的是bug修复版本，则不应该使用.postN而应该增加小的版本号。
  
• .devN（如2.3.4.dev3）表示一个开发版本。因为难以解析，所以这个后缀并不建议使用。它表示这是一个质量基本合格的发布前的版本，例如，2.3.4.dev3表示2.3.4版本的第三个开发版本，它早于任何的alpha版本、beta版本、候选版本和最终版本。
  

这一结构可以满足大部分常见的使用场景。

注意   你可能已经听说过语义版本（http://semver.org/），它对于版本号提出了自己的规则。这一规范和PEP 440部分重合，但二者并不完全兼容。例如，语义版本对 于预发布版本使用的格式1.0.0.-alpha+001就与PEP 440不兼容。

如果需要处理更高级的版本号，可以考虑一下PEP 426（http://www.python.org/dev/ peps/pep-0426）中定义的源码标签，这一字段可以用来处理任何版本字符串，并生成同PEP要求一致的版本号。

许多分布式版本控制系统（Distributed Version Control System，DVCS）平台，如Git和Mercurial，都可以使用唯一标识的散列字符串①作为版本号。但遗憾的是，它不能与PEP 440中定义的模式兼容：问题就在于，唯一标识的散列字符串不能排序。不过，是有可能通过源码标签这个字段维护一个版本号，并利用它构造一个同PEP 440兼容的版本号的。

提示   pbr（即Python Build Reasonableness，https://pypi.python.org/pypi/pbr）将在6.2节中讨论，它可以基于项目的Git版本自动生成版本号。