发布流程¶
发布节奏¶
pip 项目的发布节奏是每 3 个月发布 main 上的任何内容。这为用户提供了何时发布的预测模式，并防止长时间锁定改进以修复问题，同时仍然防止版本号大量分裂用户群。
我们的发布月份是 1 月、4 月、7 月、10 月。该月内的发布日期将由该版本的发布经理决定。如果没有更改，则会跳过该发布月份，下一个发布将在 3 个月后进行。
pip 的版本号为 YY.N，其中 YY 是发布年份，N 表示一年中的季度（0-3）。
发布经理可以自行决定是否为发布提供预发布期，如果需要，可以将此期限延长至下个月。
由于发布是直接从 main 分支进行的，因此必须始终保持 main 处于可发布状态。合并部分实现新功能的 PR 是可以接受的，但前提是部分实现的版本在此状态下可用（例如，功能减少或默认情况下被禁用）。如果发现合并的 PR 在发布之前需要额外工作，发布经理始终可以选择在发布之前撤回部分更改。然后，可以重新修改 PR 并重新提交以供下一个发布使用。
供应商更新将从 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 版本。pip 维护人员可能会将仅在 Python 2.7 上出现的 pip 错误关闭为“不会修复”问题。
Python 支持政策¶
pip 支持未到期的 CPython 版本。根据 pip 维护人员的决定，可能支持较旧版本的 CPython（基于诸如 PyPI 上的下载统计信息、供应商依赖项支持的 Python 版本和维护负担等标准）。
pip 维护人员接受支持其他 Python 实现的拉取请求，但 pip CI 不测试其兼容性。
功能标志¶
--use-deprecated¶
示例：--use-deprecated=legacy-resolver
用于将被弃用的功能。根据弃用政策，被弃用的功能应该在此标志后至少可用六个月。
移至此标志后的功能应始终包含一个警告，指示该功能何时计划删除。
删除该功能后，使用该标志的用户应看到错误。
--use-feature¶
示例：--use-feature=2020-resolver
用于用户可以在其成为 pip 的默认行为（例如 alpha 或 beta 版本）之前测试的新功能。
该功能成为默认行为后，此标志可以保留，但应发出警告，告知用户它不再必要。
发布流程¶
创建新的发布¶
确保你安装了最新的
nox。从
main创建一个新的release/YY.N分支并切换到该分支。使用
nox -s prepare-release -- YY.N准备发布。这将更新相关文件并标记正确的提交。将
release/YY.N分支作为拉取请求提交，并确保 CI 通过。将更改合并回main并将其拉回本地。使用
nox -s build-release -- YY.N构建发布工件。这将签出标签，生成要上传的发布文件，然后再次签出主分支。使用
nox -s upload-release -- YY.N将发布上传到 PyPI。推送由
prepare-release创建的标签。在 get-pip 仓库 中重新生成
get-pip.py脚本（如该文档中所述）并提交结果。向 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 仓库 发送拉取请求，将新的 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 开始。