diff --git a/pep-0596.rst b/pep-0596.rst index 777ea6065..afefeb083 100644 --- a/pep-0596.rst +++ b/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. diff --git a/pep-0602-example-release-calendar.png b/pep-0602-example-release-calendar.png index 622919fbd..1db4825f6 100644 Binary files a/pep-0602-example-release-calendar.png and b/pep-0602-example-release-calendar.png differ diff --git a/pep-0602-example-release-calendar.pptx b/pep-0602-example-release-calendar.pptx index ba01c8774..7148214e2 100644 Binary files a/pep-0602-example-release-calendar.pptx and b/pep-0602-example-release-calendar.pptx differ diff --git a/pep-0602.rst b/pep-0602.rst index 268996ca1..efb3c43d3 100644 --- a/pep-0602.rst +++ b/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 +`_ +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 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~