可能你已经有所了解，Python生态系统正在对包的元数据进行标准化。其中一项元数据就是版本号。 PEP 440（<http://www.python.org/dev/peps/pep-0440/>）针对所有的Python包引入了一种版本格式，并且在理论上所有的应用程序都应该使用这种格式。这样，其他的应用程序或包就能简单而可靠地识别它们需要哪一个版本的包。 PEP440中定义版本号应该遵从以下正则表达式的格式： `N[.N]+[{a|b|c|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](http://www.python.org/dev/peps/pep-0426)）中定义的**源码标签**，这一字段可以用来处理任何版本字符串，并生成同PEP要求一致的版本号。 许多分布式版本控制系统（Distributed Version Control System，DVCS）平台，如Git和Mercurial，都可以使用唯一标识的散列字符串[①](#anchor11)作为版本号。但遗憾的是，它不能与PEP 440中定义的模式兼容：问题就在于，唯一标识的散列字符串不能排序。不过，是有可能通过源码标签这个字段维护一个版本号，并利用它构造一个同PEP 440兼容的版本号的。 >提示 > **pbr**（即Python Build Reasonableness，<https://pypi.python.org/pypi/pbr>）将在6.2节中讨论，它可以基于项目的Git版本自动生成版本号。