[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)
|
- 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
|
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
|
this information to demonstrate that overlap between stable version
|
||||||
releases with the 12-month release cadence will be nothing new.
|
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
|
Although identified dependent policies were addressed in a previous
|
||||||
be updated:
|
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
|
Rejected Ideas
|
||||||
--------------
|
--------------
|
||||||
|
|
Loading…
Reference in New Issue