Python作為一門編程語言對用它開發的項目的版本格式沒有任何限制。實際上大多數的 Python 代碼根本沒有版本這個屬性。在 PEP345 通過之前，項目版本的格式幾乎是無關緊要的。然而這個 PEP345 給 Disutils 模塊增加了一個 Requrie-Dist 屬性，試圖通過它和其他增改的屬性來解決不同 Python 項目之間的依賴關係難以表述的問題。有了它，將來的項目可以通過原生的 Python 環境來提供自己的安裝和卸載信息，包括對其他項目的依賴。這樣 Python 就獲得了類似 Debian Linux 下面 apt-get 工具的能力！"
這個 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的中文博客， 這裡是原文連接。
