版本發佈程序¶
版本發佈時間¶
pip 專案的版本發佈時間是每 3 個月發佈一次 main 上的內容。如此一來，使用者可以預測版本發佈的時間，同時也能避免將修正的改良長時間封鎖，並防止版本號碼產生大量分歧導致使用者分散。
我們的發佈月份是 1 月、4 月、7 月和 10 月。該月份內的發佈日期將取決於負責發佈的管理人員。如果沒有變更，則會跳過該發佈月份，下一次發佈會在 3 個月後。
pip 的版本號碼是 YY.N，其中 YY 是發佈的年份，N 是該年份的季度（0-3）。
版本管理人員可以自行決定是否對版本設定預發佈時間，如果有需要，可以在下一個月延長預發佈時間。
由於版本是直接從 main 分支發佈，因此讓 main 永遠都維持在可發佈的狀態十分重要。併入只實現部分新功能的 Pull Request 是可以接受的，但前提是部分實現的版本在這種狀態下依然可以使用（例如，功能減少或預設停用）。如果發現併入的 Pull Request 在發佈前需要額外的調整，版本管理人員隨時可以在發佈前撤銷部分變更。然後可以修改後重新提交 Pull Request，以供下一次版本發佈。
供應商更新將從 main 分支接收，就像其他任何更新一樣。理想情況下，供應商更新應該在版本發佈之間併入，就像任何其他變更一樣。如果有待處理的供應商套件更新，版本管理人員可以自行決定在發佈前執行供應商更新。不過，這不是必要的，而且特別是修正 pip 問題的供應商套件更新應主動併入，以確保它們會出現在下一個版本中。
棄用政策¶
任何移除或大幅變更 pip 文件中所述使用者可見行為的 pip 變更，都必須在變更發生前至少 6 個月開始棄用。
某些變更可能快速追蹤，並且有 3 個月的棄用期。這需要至少兩位 pip 團隊成員同意這麼做，而且沒有 pip 維護者反對。
棄用將採取 pip 在該功能使用時發出警告的形式。更長的棄用期或行為變更棄用警告（通常不會受到此政策涵蓋），這也取決於情況而定，不過這由 pip 維護者決定。
請注意，文件是同意行為的唯一參考。如果文件沒有明確提到某事，這可以在發布的 pip 中不經過警告或棄用期而加以變更。不過，我們知道文件並不總是完整 - 以涵蓋該行為為目的、使用上述棄用程序記錄現有行為的 PR 始終是可以接受的，並且將根據其價值進行考量。
注意
pip 有能讓 pip 維護者更容易棄用的輔助功能。支援文件可以在 pip._internal.utils.deprecation.deprecated 來源程式碼中找到。這項功能不是 pip 公開 API 的一部分。
受支援版本 ¶
只有最新版本的 pip 受支援，之前版本應視為不受支援。建議使用者定期更新他們的 pip 版本，以維持受支援狀態。
Python 2 支援 ¶
pip 20.3 是最後一個支援 Python 2 的 pip 版本。只發生在 Python 2.7 的 pip 回報錯誤，可能會被 pip 維護者關閉為「不會修正」的問題。
Python 支援政策 ¶
pip 支援 未停產的 CPython 版本。較舊版本的 CPython 可能由 pip 維護者自行決定支援（根據基準，例如在 PyPI 上的下載統計、封送相依項支援的 Python 版本和維護負擔）。
pip 維護者接受拉取請求以支援其他 Python 實作，不過 pip CI 不測試它們的相容性。
功能標記 ¶
--use-deprecated ¶
範例： --use-deprecated=legacy-resolver
使用於會被棄用的功能。依據棄用政策，已被棄用的功能應在此標記下至少維持六個月。
移至此標記之後的功能皆應包含一個警告，指出該功能排定的移除時間。
在移除功能時，應該向使用該標記的使用者顯示錯誤。
--use-feature¶
範例：--use-feature=2020-resolver
用於可以在新功能成為 pip 的預設行為 (例如，alpha 或 beta 版本) 之前由使用者測試的新功能。
當此功能成為預設行為後，此標記可以持續存在，但應發出一個警告告訴使用者，此功能不再必要。
發布流程¶
建立新版本¶
確保您安裝了最新的
nox。建立一個新的
release/YY.N分支，並從main切換到該分支。使用
nox -s prepare-release -- YY.N準備發布。這將更新相關檔案，並標記正確的提交。將
release/YY.N分支提交為一個 pull request，並確保 CI 通過。將變更合併回main，並將它們拉回至本地端。使用
nox -s build-release -- YY.N建立發布品。這將 checkout 標記、產生要上傳的發行檔案，並再次 checkout main 分支。使用
nox -s upload-release -- YY.N將發布品上傳至 PyPI。傳送出
prepare-release建立的標記。在 get-pip 儲存庫 中重新產生
get-pip.py腳本 (如說明文件所示)，並提交結果。提交一個 Pull Request 至 CPython，將 pip 的新版本加入至
Lib/ensurepip/_bundled中，移除現有版本，並調整在Lib/ensurepip/__init__.py中列出的版本。
注意
如果這個版本棄用某個過時 Python 版本 M.m，這樣就需要發布一個新的 M.m/get-pip.py：從 get-pip 儲存庫 中的 tasks/generate.py 更新 all 任務，並向 psf-salt 儲存庫 發出一個 pull request，將新的 get-pip.py（及其目錄）加入 salt/pypa/bootstrap/init.sls。
注意
如果由於 pip 內部的變更而需要更新 get-pip.py 這個腳本，而且最後發布的 M.m/get-pip.py 仍使用預設範本，請務必先將 templates/default.py 複製成 templates/pre-YY.N.py，然後再更新它，並在 tasks/generate.py 中指定 M.m/get-pip.py 現在需要使用 templates/pre-YY.N.py。
建立修正錯誤版本¶
有時我們需要發布一個格式為 YY.N.Z+1 的修正錯誤版本。要建立這樣的版本，變更內容應該已經合併到 main 分支中。
請注意，這個程序只有在你希望在修正錯誤版本中不納入 main 分支中的變更時才需要。對於要納入 main 分支中所有內容的修正錯誤版本，可以使用上述建立新版本的程序，只需變更版本號碼即可。
使用指令
git checkout -b release/YY.N.Z+1 YY.N從YY.N標籤建立一個新的release/YY.N.Z+1分支。從
main分支選擇並取用已修正的提交，並修正任何衝突。執行
nox -s prepare-release -- YY.N.Z+1。將 main 合併到你的版本分支中，並放棄版本中所包含的新聞檔案（否則它們也會出現在
YY.N+1變更日誌中）將
release/YY.N.Z+1分支推送到 github，並針對main分支提交 PR，等待執行測試。測試執行完畢後，將
release/YY.N.Z+1分支合併到main，並從步驟 5 開始，執行上述發行程序。