PEP 605: A rolling feature release stream for CPython

The Windows analogy works well for me, and yes, I avoid the insider builds. So I would probably stick to the Python stable releases, for similar reasons.

As a user, yes, I guess so. Although it’s the 2 year release cycle, rather than the 3.9 release date that matters to me, so shifting the start doesn’t help that much. The actual schedule you quoted (Apr 2021, Aug 2022, Aug 2024) seems a lot more palatable, but it feels like you’re just easing people into the new schedule, and I feel that I should take a view on the actual proposal, not the transition (even though the transition takes 5 years, by which time anything could have happened!)

Ultimately I look at it from a few perspectives:

  1. As a user, faster releases is good so my preference is PEP 602 (Annual), the status quo (18 month) then PEP 605 (biannual, but with complications ;-)) in that order.
  2. As a library maintainer (of libraries that don’t have C code), mostly neutral as we’re more driven by the oldest version we need to support and until Python 2 is finally gone, new features are irrelevant. Faster Python releases might add extra work, but I doubt it’s a lot.
  3. As a consumer of other people’s code, simpler and “not too fast to deter shipping binaries” is better. But as I can only speculate on how the projects I use would be affected, it’s mostly guesswork. The change-averse part of me says that PEP 605 is the loser here simply because the whole beta/ABI compatibility stuff is fundamentally more complex than the status quo, whereas a frequency change is easy to reason about.
  4. As a core developer, I’m not sufficiently involved in release management to feel like I should offer an opinion. If the RMs are happy, so am I.

But overall, I’ve spent way more time considering the implications of this proposal than I ever have on any other aspect of Python’s release schedule. And certainly more than any benefit I’d get would justify.

Agreed, and I hope I’m relatively accurately representing the portion of the userbase that works like I do. But I equally think that people like me are probably the most flexible group, in practice. Getting feedback from organisations that build products in Python is probably way more important here, but they are the group that it’s generally hardest to get input from (because they are often least engaged with open source communities).

Have we had any feedback from organisations like Heroku or Python Anywhere?

1 Like

hi, my own experience trying to build a full WinPython along the Python-3.8 development process:

  • playing well the “python next” game were cpython maintainer and cgohlke,
  • playing not so well was the lack of continuous integration options for package maintainers entirely relying on it,
  • sad experience was the very late community reaction on breaking change to the ProActorEventLoop switch on Windows that occured in beta1 https://bugs.python.org/issue37373 .

So, I would suggest:

  • ensure that there are “continuous integration” branches following each alpha/beta cycle, available to fundation packages at least,
  • plan a small “war group” on each breaking change that is intended, to identify what must be critically adapted downward and help on it, so that the change is a joy at RC time, rather than a continuous pain, for maybe until the next Python cycle.

Having a full Distro released between each alpha/beta cycle is a third step, maybe a too far objective at this point, and too much diluting of force.