[pep-602] Address dependent policies

This commit is contained in:
Łukasz Langa 2019-10-24 12:09:50 +02:00
parent 06b91948ca
commit ddfd96df13
No known key found for this signature in database
GPG Key ID: B26995E310250568
1 changed files with 38 additions and 8 deletions

View File

@ -111,6 +111,39 @@ release schedule:
- 3.9.0 final: Monday, 2021-04-19 (6 months later)
Dependent Policies
==================
Deprecations
------------
The current policy around breaking changes assumes at least two releases
before a deprecated feature is removed from Python or a ``__future__``
behavior is enabled by default. This is documented in PEP 387.
This PEP proposes to keep this policy of **at least** two releases
before making a breaking change.
The term of the Steering Council
--------------------------------
The current wording of PEP 13 states that "a new council is elected
after each feature release". This PEP proposes to keep this policy
as it will lead to a consistent election schedule.
The term of the Release Manager
-------------------------------
The current undocumented convention is for a single Release Manager to
handle two feature releases of Python. This PEP proposes to keep this
policy, allowing for the term to be extended to more releases with
approval from the Steering Council and the Cabal of Release Managers.
In particular, since this PEP is authored by the active Release Manager
and its effect would shorten the term of the Release Manager, the author
is open to managing the release of a third feature release to compensate
for the disruption.
Rationale and Goals
===================
@ -204,16 +237,13 @@ of the next version for around six months. Figure 2 is including
this information to demonstrate that overlap between stable version
releases with the 12-month release cadence will be nothing new.
Some policies depend on the release cadence
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Other policies may depend on the release cadence
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
The following policies depend on the release cadence and will have to
be updated:
Although identified dependent policies were addressed in a previous
section, it is entirely possible there are some other areas which
implicitly rely on the timing of Python releases.
- the deprecation policy
- the ``__future__`` import becoming the default
- the term of the Steering Council
- the term of the Release Manager
Rejected Ideas
--------------