[pep-602] Address dependent policies
This commit is contained in:
parent
06b91948ca
commit
ddfd96df13
46
pep-0602.rst
46
pep-0602.rst
|
@ -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
|
||||
--------------
|
||||
|
|
Loading…
Reference in New Issue