Release Process and Rules

v2.6.2 新版功能.

Starting with the version to be released after v2.6.2, the following ruleswill govern and describe how the Requests core team produces a new release.

Major Releases

A major release will include breaking changes. When it is versioned, it willbe versioned as vX.0.0. For example, if the previous release wasv10.2.7 the next version will be v11.0.0.

Breaking changes are changes that break backwards compatibility with priorversions. If the project were to change the text attribute on aResponse object to a method, that would only happen in a Major release.

Major releases may also include miscellaneous bug fixes and upgrades tovendored packages. The core developers of Requests are committed to providinga good user experience. This means we're also committed to preservingbackwards compatibility as much as possible. Major releases will be infrequentand will need strong justifications before they are considered.

Minor Releases

A minor release will not include breaking changes but may includemiscellaneous bug fixes and upgrades to vendored packages. If the previousversion of Requests released was v10.2.7 a minor release would beversioned as v10.3.0.

Minor releases will be backwards compatible with releases that have the samemajor version number. In other words, all versions that would start withv10. should be compatible with each other.

Hotfix Releases

A hotfix release will only include bug fixes that were missed when the projectreleased the previous version. If the previous version of Requests releasedv10.2.7 the hotfix release would be versioned as v10.2.8.

Hotfixes will not include upgrades to vendored dependencies afterv2.6.2

Reasoning

In the 2.5 and 2.6 release series, the Requests core team upgraded vendoreddependencies and caused a great deal of headaches for both users and the coreteam. To reduce this pain, we're forming a concrete set of procedures soexpectations will be properly set.