Chromium Code Reviews
chromiumcodereview-hr@appspot.gserviceaccount.com (chromiumcodereview-hr) | Please choose your nickname with Settings | Help | Chromium Project | Gerrit Changes | Sign out
(125)

Side by Side Diff: recipe_engine/third_party/requests/docs/community/release-process.rst

Issue 2164713003: Vendor requests. (Closed) Base URL: https://chromium.googlesource.com/external/github.com/luci/recipes-py@master
Patch Set: Fix deps.pyl Created 4 years, 5 months ago
Use n/p to move between diff chunks; N/P to move between comments. Draft comments are only viewable by you.
Jump to:
View unified diff | Download patch
OLDNEW
(Empty)
1 Release Process and Rules
2 =========================
3
4 .. versionadded:: v2.6.2
5
6 Starting with the version to be released after ``v2.6.2``, the following rules
7 will govern and describe how the Requests core team produces a new release.
8
9 Major Releases
10 --------------
11
12 A major release will include breaking changes. When it is versioned, it will
13 be versioned as ``vX.0.0``. For example, if the previous release was
14 ``v10.2.7`` the next version will be ``v11.0.0``.
15
16 Breaking changes are changes that break backwards compatibility with prior
17 versions. If the project were to change the ``text`` attribute on a
18 ``Response`` object to a method, that would only happen in a Major release.
19
20 Major releases may also include miscellaneous bug fixes and upgrades to
21 vendored packages. The core developers of Requests are committed to providing
22 a good user experience. This means we're also committed to preserving
23 backwards compatibility as much as possible. Major releases will be infrequent
24 and will need strong justifications before they are considered.
25
26 Minor Releases
27 --------------
28
29 A minor release will not include breaking changes but may include
30 miscellaneous bug fixes and upgrades to vendored packages. If the previous
31 version of Requests released was ``v10.2.7`` a minor release would be
32 versioned as ``v10.3.0``.
33
34 Minor releases will be backwards compatible with releases that have the same
35 major version number. In other words, all versions that would start with
36 ``v10.`` should be compatible with each other.
37
38 Hotfix Releases
39 ---------------
40
41 A hotfix release will only include bug fixes that were missed when the project
42 released the previous version. If the previous version of Requests released
43 ``v10.2.7`` the hotfix release would be versioned as ``v10.2.8``.
44
45 Hotfixes will **not** include upgrades to vendored dependences after
46 ``v2.6.2``
47
48 Reasoning
49 ---------
50
51 In the 2.5 and 2.6 release series, the Requests core team upgraded vendored
52 dependencies and caused a great deal of headaches for both users and the core
53 team. To reduce this pain, we're forming a concrete set of procedures so
54 expectations will be properly set.
OLDNEW

Powered by Google App Engine
This is Rietveld 408576698