Python程序员常弄混的包版本表示

Python包版本表面上看起来很简单，但是同一般业界通用的定义良好的版本方案却不一样，有点诡异。比如正常的版本表示都为SemVer 1.2.3或CalVer 2023.6.1，有时候还有带预发布版本后缀的，比如1.2.3pre1。但是Python包版本控制可能会有些不一样，本文虫虫就给大家介绍一些python包的版本管理。

概述

由于 Python 版本的复杂性，本文应作为不将Python版本作为简单字符串处理的原因列表。而是使用官方packaging.version.Version类。该类可以解析、比较和推理Python版本

PEP440的Python包版本的当前最新的标准。基于PEP440的规定，目前绝大多数的Python包（大概97%软件包）都使用这种方式。

Python包版本由最6种类型的“版本部分”组成。其中一个是必需的“Release”部分和3个常见的可选部分，分别称为“Pre-releases”、“Post-releases”和“Dev”。其余2个可选且不太常见的部分是“Epoch”和“Local”版本部分。下面的图表显示了版本部分的所有类型、它们的排序方式以及分隔符是什么：

v前缀

任何版本号都可以以v前缀可选的开头。该字符在规范化过程中会被剥离，并且不携带有关版本的任何进一步数据。

时间纪元（Epoch）版本

Epoch版本为包提供了一种更改其版本控制方案的方法，而无需承担过去版本控制的负担影响哪个版本将被视为“最新”的方案。 例如，如果项目使用大量第一个发行版本段可能会很笨重，然后使用更大的数字来“摆脱”之前的版本控制方案。

根据PEP440：

特别是，支持版本纪元允许之前使用基于日期的版本控制的项目通过指定新版本纪元切换到语义版本控制。

Local版本

local版本是由字母数字和句点组成的任意标识符，位于“release”之后。本地版本没有任何预定义的语义，但通常用于区分上游版本来自下游集成商可能改变的重建。

本地版本“段”可以通过以下方式分隔 ., -，或者_但所有这些字符都会规范化为.:

注意：本地版本也无法上传到PyPI，该服务将拒绝它们：

PEP 中明确指出了这种行为：

由于Python包索引仅用于索引和托管上游项目，因此它不得允许使用本地版本标识符。

版本长度

PEP 440没有定义版本号的最大长度，所以可以是任意长度。例如，有的包使用了pi的前217位作为其版本号。

大小写

版本号都会被规范化为小写：

Pre-post-dev发布

Pre、post和dev版本部分并不是唯一的，可以将所有三个版本合并为一个，比如：

分隔符

Pre、post和dev版本部分都有一个可选的分隔符（-, _，或者.），这些部分可以组合在一起，而无需任何字符将它们分开，可以拥有包含所有三个的版本：

和“rc“相似的”cr”也是一个有效的版本标识符，但是两者意思完全，因为c表示预发布，但是r表示发布后：

比如

分隔符规范化

alpha、beta、候选版本后缀在没有分隔符的情况下进行规范化，但post和开发版本后缀则使用分隔符进行规范化：

隐式post

有连字符分隔符“-”并且任何release版本后面的数字相当于post：

隐式零

版本1.0和1.0.0表示不同的版本号。Release部分会自动将缺少的版本段添加零，以便两者比较相同的值。

所以可以在版本后添加大量零， pip可以很好地自动处理它：

数值归一化

所有整数均通过int()内置意味着它们将规范化，去掉前缀零无，成无错误的整数：

PEP440之前版本的不明确解析

PEP 440 于2014年才生效，在此之前已经发布了很多Python包了，对版本的PEP440规则的追溯应用可能会导致源发行版出现一些不明确的解析情况。

Wheel编译版本

Wheel编译版本号是一个与版本号非常相似的功能，并且仅适用于Wheel发行版。当两个包具有相同的名称、版本、平台、Python 和ABI标签时，这个版本号将用来区分比较两个版本。

从PEP 427开始，内部版本号位于Wheel文件名中的名称和版本之后：

所以可以拥有两个具有相同名称、版本和标签但仍不相同的发行版到Wheel版本号。除了锁定文件中的版本之外，固定哈希值也很重要的又一个原因。

综上，dist名称为0可以对应有一个名为 0-0-0-0-py3-any-none.whl的文件