发布流程和规则

新版本 v2.6.2。

从 v2.6.2 之后要发布的版本开始，以下规则将管理和描述 Requests 核心团队如何生成新版本。

主要发布

主要版本将包括重大更改。版本化时，将版本化为 vX.0.0。例如，如果以前的版本是 v10.2.7，下一个版本将是 v11.0.0。

破坏性更改是破坏与先前版本的向后兼容性的更改。如果项目要将 Response 对象上的 text 属性更改为方法，那只会发生在主要版本中。

主要版本还可能包括各种错误修复。 Requests 的核心开发者致力于提供良好的用户体验。这意味着我们还致力于尽可能地保持向后兼容性。主要版本将很少出现，并且在考虑之前需要强有力的理由。

次要版本将不包括重大更改，但可能包括各种错误修复。如果之前发布的 Requests 版本是 v10.2.7，那么次要版本将被版本化为 v10.3.0。

次要版本将向后兼容具有相同主要版本号的版本。换句话说，所有以 v10. 开头的版本都应该相互兼容。

修补程序版本将仅包含项目发布先前版本时遗漏的错误修复程序。如果先前版本的 Requests 发布 v10.2.7，则修补程序版本将版本化为 v10.2.8。

修补程序将不包括在 v2.6.2 之后对供应商依赖项的升级

在 2.5 和 2.6 版本系列中，Requests 核心团队升级了vendored 的依赖，给用户和核心团队带来了很大的麻烦。为了减轻这种痛苦，我们正在制定一套具体的程序，以便正确设定期望。