Python 3.8.4rc1 is the release candidate of the fourth maintenance release of Python 3.8. Go get it here:
Assuming no critical problems are found prior to 2020-07-13, the scheduled release date for 3.8.4, no code changes are planned between this release candidate and the final release.
That being said, please keep in mind that this is a pre-release and as such its main purpose is testing.
Maintenance releases for the 3.8 series will continue at regular bi-monthly intervals, with 3.8.5 planned for mid-September 2020.
The Python 3.8 series is the newest feature release of the Python language, and it contains many new features and optimizations. See the “What’s New in Python 3.8 <https://docs.python.org/3.8/whatsnew/3.8.html>” document for more information about features included in the 3.8 series.
This is the first bugfix release that is considerably smaller than the previous three. There’s 20% less changes at 130 commits than the average of previous three releases. Detailed information about all changes made in version 3.8.4 specifically can be found in its change log <https://docs.python.org/release/3.8.4rc1/whatsnew/changelog.html#python-3-8…>.
We hope you enjoy Python 3.8!
Thanks to all of the many volunteers who help make Python Development and these releases possible! Please consider supporting our efforts by volunteering yourself or through organization contributions to the Python Software Foundation.
Your friendly release team,
Ned Deily @nad <https://discuss.python.org/u/nad>
Steve Dower @steve.dower <https://discuss.python.org/u/steve.dower>
Łukasz Langa @ambv <https://discuss.python.org/u/ambv>
We will be accecpting commits to the 3.7 branch until this coming Monday 06-15 23:59 AOE. At that time, 3.7 will effectively enter security-fix mode. That will also be the deadline for any additional security-fixes for release in 3.6.11. Release candidates will follow shortly thereafter. Assuming no release-blocker issues arise during the release candidate testing, 3.7.8 and 3.6.11 will release on 06-27.
nad(a)python.org -- 
Changes on CIs run on GitHub pull requests:
* Travis CI became mandatory
* Azure Pipelines is no longer mandatory
* Please watch Windows x64 job: I would like to make it mandatory in 2 weeks
I asked to make Azure Pipelines CI not mandatory on Python PRs since
there were more and more random failures and no one was available to
investigate. Also, sadly, currently Azure Pipelines has no way to only
re-trigger a single failed job, but requires to close/re-open a PR to
schedule all jobs. Sadly, some Python tests fail randomly and so
sometimes another CI fails. Also, for backport PRs, closing a PR
triggers miss-inlington which removes the branch which prevents to
re-open the PR. A new backport PR must be created which is not
Until Azure Pipelines issues are fixed, I asked Mariatta to make
Travis CI mandatory. In fact, I expected Travis CI to be mandatory, I
never noticed that it was optional. I didn't know that only Azure
Pipelines was mandatory!
I also asked Mariatta to make the GitHub Action ("GHA") Windows x64
job mandatory. GHA workflow jobs are skipped for "documentation only"
changes, to not waste CI resources. GHA configuration used
"paths-ignored". Sadly (again!?), if a job using "paths-ignored" is
mandatory, a PR cannot be merged because the mandatory job is skipped
and will never be run... Sadly, it even seems to be a known GitHub
issue which is not going to be fixed soon!
I removed "paths-ignored" to always run jobs, to be able to make a job
mandatory. Then Filipe Laíns found a way to add a new quick (around 15
seconds!) job just for check if a change is documentation only: the
job result is then used to decide if build jobs must be skipped.
In short, the behavior is the same than previously: GHA build jobs are
skipped on documentation only changes. The main difference is that it
became possible to make a GHA job mandatory.
I backported the GHA workflow configuration to Python 3.8 and 3.7.
Mariatta suggested to watch the Windows x64 job for 2 weeks to check
if it's stable before making it mandatory.
Hopefully, in my experience, the Windows x64 job is (very) reliable.
By the way, the GHA macOS job fails randomly, I have no idea why. For
example, I saw the job being cancelled after 5 minutes for an unknown
reason. I read that a job can be cancelled if "fail fast" is used and
another job fails. It doesn't seem like we use "fail fast" and others
jobs passed successfully.
Links to CI changes.
Make Azure Pipelines optional on GitHub PRs:
Always run GitHub action jobs, even on documentation-only jobs:
Make one Windows CI job mandatory:
Make Travis CI (and Windows x64 ?) mandatory:
Make Windows (x64) GitHub action mandatory on master branch:
It's so hard to get a bunch of reliable CIs on many platforms (Linux,
Windows, macOS) and minimize the failure rate :-(
Night gathers, and now my watch begins. It shall not end until my death.