发布流程和规则¶

在 v2.6.2 版本加入.

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

及主版本升级软件¶

一个主要的版本将包括突破性的改变。当它被版本化时，它将被版本化为 vX.0.0 . 例如，如果以前的版本是 v10.2.7 下一个版本是 v11.0.0 .

中断更改是指中断与以前版本的向后兼容性的更改。如果项目要改变 text 属性上的 Response 对象到方法，这只在主版本中发生。

主要版本还可能包括其他错误修复。请求的核心开发人员致力于提供良好的用户体验。这意味着我们还致力于尽可能地保持向后兼容性。主要的发布将是罕见的，并将需要强有力的理由，然后才被考虑。

次要版本不包括中断更改，但可能包括其他错误修复。如果以前发布的请求版本是 v10.2.7 一个次要版本将被版本化为 v10.3.0 .

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

热修复版本将只包括在项目发布前一版本时错过的错误修复。如果以前版本的请求已发布 v10.2.7 热修复版本将被版本化为 v10.2.8 .

修补程序将 not 包括在以下时间之后升级到自动添加的依赖项 v2.6.2

在2.5和2.6版本系列中，请求核心团队升级了供应商提供的依赖项，并给用户和核心团队带来了很多麻烦。为了减少这种痛苦，我们正在形成一套具体的程序，以便正确设定预期。