[pep-602] [pep-569] Adjust beta phase
You're welcome Fedora ;-) ...and thanks for all your help!
This commit is contained in:
Łukasz Langa
parent
a2ae50206b
commit
493dc56d8c
23
pep-0596.rst
23
pep-0596.rst
|
|
@ -46,21 +46,20 @@ PEP 602. Suggestions and comments welcome.
|
|||
Expected:
|
||||
|
||||
- 3.9 development begins: Tuesday, 2019-06-04
|
||||
- 3.9.0 alpha 1: Monday, 2019-10-14
|
||||
- 3.9.0 alpha 2: Monday, 2019-11-18
|
||||
- 3.9.0 alpha 3: Monday, 2019-12-16
|
||||
- 3.9.0 alpha 4: Monday, 2020-01-13
|
||||
- 3.9.0 alpha 5: Monday, 2020-02-17
|
||||
- 3.9.0 alpha 6: Monday, 2020-03-16
|
||||
- 3.9.0 alpha 7: Monday, 2020-04-13
|
||||
- 3.9.0 alpha 1: Monday, 2019-11-18
|
||||
- 3.9.0 alpha 2: Monday, 2019-12-16
|
||||
- 3.9.0 alpha 3: Monday, 2020-01-13
|
||||
- 3.9.0 alpha 4: Monday, 2020-02-17
|
||||
- 3.9.0 alpha 5: Monday, 2020-03-16
|
||||
- 3.9.0 alpha 6: Monday, 2020-04-13
|
||||
- 3.9.0 beta 1: Monday, 2020-05-18
|
||||
(No new features beyond this point.)
|
||||
|
||||
- 3.9.0 beta 2: Monday, 2020-06-15
|
||||
- 3.9.0 beta 3: Monday, 2020-07-13
|
||||
- 3.9.0 beta 4: Monday, 2020-08-17
|
||||
- 3.9.0 candidate 1: Monday, 2020-09-14
|
||||
- 3.9.0 candidate 2: Monday, 2020-09-21 (if necessary)
|
||||
- 3.9.0 beta 2: Monday, 2020-06-08
|
||||
- 3.9.0 beta 3: Monday, 2020-06-29
|
||||
- 3.9.0 beta 4: Monday, 2020-07-20
|
||||
- 3.9.0 candidate 1: Monday, 2020-08-10
|
||||
- 3.9.0 candidate 2: Monday, 2020-09-14
|
||||
- 3.9.0 final: Monday, 2020-10-05
|
||||
|
||||
Subsequent bugfix releases at a monthly cadence.
|
||||
|
|
|
|||
Binary file not shown.
|
Before Width: | Height: | Size: 356 KiB After Width: | Height: | Size: 356 KiB |
Binary file not shown.
46
pep-0602.rst
46
pep-0602.rst
|
|
@ -36,15 +36,16 @@ This PEP proposes that Python 3.X.0 will be developed for around
|
|||
- The next *seven months* are spent on versioned alpha releases where
|
||||
both new features are incrementally added and bug fixes are included.
|
||||
|
||||
- The following *four months* are spent on versioned beta releases where
|
||||
**no new features** can be added but bug fixes are still included.
|
||||
- The following *three months* are spent on four versioned beta releases
|
||||
where **no new features** can be added but bug fixes are still
|
||||
included.
|
||||
|
||||
- The *final month* is spent on a release candidate (or more, if
|
||||
necessary) and concludes with the release of the final release of
|
||||
- The final *two months* are spent on two release candidates (or more,
|
||||
if necessary) and conclude with the release of the final release of
|
||||
Python 3.X.0.
|
||||
|
||||
One year of full support, four more years of security fixes
|
||||
-----------------------------------------------------------
|
||||
1½ year of full support, 3½ more years of security fixes
|
||||
--------------------------------------------------------
|
||||
|
||||
After the release of Python 3.X.0, the 3.X series is maintained for
|
||||
five years:
|
||||
|
|
@ -81,11 +82,11 @@ Example
|
|||
- 3.9.0 beta 1: Monday, 2020-05-18
|
||||
(No new features beyond this point.)
|
||||
|
||||
- 3.9.0 beta 2: Monday, 2020-06-15
|
||||
- 3.9.0 beta 3: Monday, 2020-07-13
|
||||
- 3.9.0 beta 4: Monday, 2020-08-17
|
||||
- 3.9.0 candidate 1: Monday, 2020-09-14
|
||||
- 3.9.0 candidate 2: Monday, 2020-09-21 (if necessary)
|
||||
- 3.9.0 beta 2: Monday, 2020-06-08
|
||||
- 3.9.0 beta 3: Monday, 2020-06-29
|
||||
- 3.9.0 beta 4: Monday, 2020-07-20
|
||||
- 3.9.0 candidate 1: Monday, 2020-08-10
|
||||
- 3.9.0 candidate 2: Monday, 2020-09-14
|
||||
- 3.9.0 final: Monday, 2020-10-05
|
||||
|
||||
.. figure:: pep-0602-example-release-calendar.png
|
||||
|
|
@ -168,6 +169,12 @@ This change provides the following advantages:
|
|||
- decreases the urge to rush features shortly before "Beta 1" due to
|
||||
the risk of them "slipping for 18 months";
|
||||
|
||||
- allows for synchronizing the schedule of Python release management
|
||||
with external distributors like Fedora who've been historically very
|
||||
helpful in finding regressions early not only in core Python but also
|
||||
in third-party libraries, helping moving the community forward to
|
||||
support the latest version of Python from Day 1;
|
||||
|
||||
- increases the explicit alpha release phase, which provides meaningful
|
||||
snapshots of progress on new features;
|
||||
|
||||
|
|
@ -285,8 +292,21 @@ Double the release cadence to achieve 9 months between major versions
|
|||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
This was originally proposed in PEP 596 and rejected as both too
|
||||
irregular and too short. One consequence of a 9 month release cadence
|
||||
was shortening of the beta phase and this was considered dangerous.
|
||||
irregular and too short. This would not give any of the benefits of
|
||||
a regular release calendar but it would shorten all development phases,
|
||||
especially the beta + RC phases. This was considered dangerous.
|
||||
|
||||
Keep "4 betas over 4 months and a final month for the release candidate"
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
While this would make the release calendar a bit cleaner, `it would make
|
||||
it very hard for external distributors like Fedora
|
||||
<https://discuss.python.org/t/pep-602-annual-release-cycle-for-python/2296/79?u=ambv>`_
|
||||
to release the newest version of Python as soon as possible. We are
|
||||
adjusting Python's calendar here in the hope that this will enable
|
||||
Fedora to integrate the newest version of Python with the newest version
|
||||
of Fedora *as both are being developed* which makes both projects
|
||||
better.
|
||||
|
||||
Slow down releases but don't freeze feature development with Beta 1
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
|
|
|||
Loading…
Reference in New Issue