I’ve been talking about a possible alternative with a few people and wanted to summarise it here, and I give permission to merge it into the PEP as a [rejected] alternative (or we can move the current proposal into rejected ones I guess 
)
Fast and Stable releases
The main goal is to minimize the number of releases in bugfix mode (that period between the x.y.0 release and entering security fix-only mode) and also minimize the time between new code/features being merged and becoming available to users.
In short, we have a stable release series that looks basically the same as our current releases (3.x.y). The main bugfix period becomes 2 years, and security-fix period remains as it is. The next release’s beta is 6 months (or 3, I don’t really mind) overlapping with the end of the previous version’s bugfix, so that we only ever have one stable release taking bugfixes.
We also have a fast release series that is calendar versioned (“2019-09”, “2019-10”, etc.) and releases from master every month (or I could see every three months being reasonable). This becomes like a continuous alpha release, and of course us core developers have to take compatibility seriously all the time to avoid breaking users unnecessarily.
In pictures (version numbers and months selected arbitrarily - can realign however we want):
One fast release each month, six-month beta periods and 24-month bugfix:
Alternatively, one fast release every three months and stable releases as above:
For users, the implications are:
- if you’re on fast track release
X-20YY, you won’t get bugfixes unless you update to(X+1)-20YY - if you’d prefer a slower release, there is exactly one current release, and potentially one beta release (for those whose job it is to make sure it works before upgrading their user’s CPython version)
For library developers:
- your own stable releases should work with stable track CPython, and may work with fast track (if desired)
- your own prereleases should probably work with fast track, if you want early-adopting users to be able to give you feedback
- your minimal test matrix is “current fast track release” and “current stable/bugfix release”, optionally also testing the beta stable release when available
For core developers:
- fast track and stable must install side-by-side
- we have to become more careful about making any breaking changes (or face broken users within 1-3 months), and probably think about better use of runtime or per-module feature flags