There seems to be a fundamental disconnect here, where folks seem to think Steve and I want everyone to start using the rolling releases. We don’t - we only want folks that are thoroughly dissatisfied with the slower full release cadence to use them.
Users in that position aren’t going to be deterred by the beta label, or the fact that alphas & betas potentially become intermingled: they’ll only be deterred by a genuinely bad developer experience on the rolling release stream (which the PEP aims to avoid).
If folks with the expectation “this is exactly like using one of the stable releases” were to start using the rolling release stream, that would be a communication failure, rather than a success.
The real test of suitability would probably be that first mid-stream alpha release, where the ABI gets changed, and at least some third party packages need to be rebuilt due to segfaults. If folks get bitten by that, I assume at least some of them would say “This is not for me” and go back to the stable release series. But a lot would say “This is what I signed up for”, install whatever library updates were needed, and continue on.
Globally, my guess is that the latter group would number somewhere in the thousands (somewhere between 0.1% and 1% of our user numbers), which should be sufficient for more robust pre-release feedback. It wouldn’t be the millions that use the stable releases, but that’s a large part of the point: encouraging a larger group of self-selected early adopters to contribute to improving API designs before we lock them down in a stable release for the rest of our multiple-orders-of-magnitude larger overall user community.
On that front, perhaps it would make sense for me to mock up some example alpha, beta and release candidate announcements, based on the 3.8.0 pre-release cycle?
If the PEP were to be adopted, I would expect those announcements, along with a What’s New section for them to link to, would be our main tool for communicating the process change outside the core development group.
(trawling the “Include/” commit history should also give me some stats on how many potential ABI changes there actually were during 3.8.0 development)
Mostly because of PEP 440 (and the related PEP 508): if we introduce a new release type into the version number itself, we’d have to update the various packaging interoperability specs to cope with it. In particular, PEP 508 defines the “python_full_version” marker (3.9.0a1, etc), and then refers back to PEP 440 for the rules on how to order Python versions.
The main reason I could see us some day tweaking the formal naming is if everything is going wonderfully well with the rolling releases, but there are some environments that are operationally capable of handling the rolling release stream, but have an explicit policy requirement that says “No beta software”.
That kind of context is essentially the only time I could see the difference between “Formally defined as ‘binary compatible’ release, informally known as ‘beta’ releases” and “Formally defined as ‘beta’ releases” actually mattering.
We’re a long way from needing to worry about that, though - even if PEP 605 were to be adopted for 3.9, changing the rolling release type names would be a topic for 3.10 at the earliest.
I ended up using completely hypothetical ABI break examples, as finding them without a clear marker in the commit log is tricky. I did use the real 3.8.0a1 and 3.8.0rc1 announcements as my base templates, though.
I don’t know. But other people still occasionnally look at how Python’s release process works, and they may even sometimes, out of curiosity, decide to try out an alpha or beta version. So these other people can end up confused as well.
So just to be clear, then, for the vast majority of end users you intend this proposal to be a change from an 18-month release cycle to a 2 year release cycle?
Given that your intention is for the “rolling feature release” stream to be only applicable to a tiny minority of Python users, I think it would be clearer if you presented this proposal as a 2-year release cycle with an improved process for those people who wanted to be involved in test releases.
Unless I’m still misunderstanding the intention here…
To give my personal view, as an end user, I’m not “thoroughly dissatisfied” with the longer release cycle, but I dislike it. So I guess I’m in the category of people who prefer the current situation (or the annual cycle Łukasz is proposing) but would have to put up with a longer release cycle if this proposal was accepted. So still -1, I guess…
From my understanding, it’s not only targeted at those who are interested in test releases. In theory, it would eventually become appealing to anyone who wants to have early features and doesn’t have a critical need for stability. OTH, the current alpha and beta versions are pretty much exclusively appealing to testers and library maintainers.
Also, when Nick was referring to 0.1 to 1% of the user base, I think he was talking about the initial percentages for the first mid-stream alpha release, not the long term usage rates. It will likely remain a minority in comparison to the stable releases, but not to that degree.
Nick has thought about this aspect more than me, but the intent is to communicate that “this release will require non-stable ABI extension modules to be recompiled, and existing platform-specific wheels will fail to load”. So I’d say breaking, as an augmentation that doesn’t break anything wouldn’t require this warning.
And yes, it’s changing the definition from what we currently have. The first RC becomes the point where everything is frozen, but then we plan on having it in RC for two months and would no doubt (informally) discourage major ABI changes in the last couple of pre-RC releases.
Ah, nope. We’re actually proposing coming down really hard on the stable ABI and disallowing changes to it after something is added to any pre-release. So if something shows up in say X.Yb7, it’s guaranteed stable in X.Y. Which really raises the bar on the stable ABI, but treating it that seriously is the only way to help library developers trust that they can rely on it. And if they do, they get out completely from the p ABI flag as well, and aren’t forced to rebuild for the RC release.
But it’s an added burden on the core dev side, for sure. (Of course, it’s very easy to avoid by not adding your new API to the stable ABI until you’ve tested it in the CPython API and know it’s ready )
That part isn’t technically a change, since the existing range is 18-24 months. It did seem worth making explicit that the intent is to move consistently to the longer end of the range though, so the PEP does clearly call it out. (It’s also not an intrinsic part of the proposal, as everything would still work the same way for an 18 month cycle. As the PEP itself now says, the only strict connection is that the PEP should mitigate the downsides of the longer cycle enough that the upsides win out)
Thus the focus of the proposal is to make the beta release stream just as usable as the stable releases, except features may come and go with every new beta. That currently isn’t the case, as the existing system means providing version specific pre-built wheel archives is discouraged prior to ABI freeze, and we actively discourage production use of everything except the final release.
However, most folks aren’t dissatisfied with the stable releases, and waiting 6 months isn’t going to matter to most users (even today there are folks that choose to only upgrade every 36 months or more).
Thus, if the PEP were to be accepted, I would expect there to be a self-selection effect where users sorted themselves into the following update cycles:
24-48+ months (i.e. skipping some stable releases, with Red Hat being a notable member of this category)
24 months (i.e. every stable release, with Canonical and Debian being notable members of this category)
annual (e.g. stable release & X.Y.0b6 or so)
twice yearly (i.e. latest beta at that time)
quarterly (also latest beta at that time)
every non-alpha release
every pre-release (including alphas)
It’s those last two groups that I expect to be a relatively small portion of our user base overall, whereas the “selective use of pre-releases” groups would be larger.
As the PEP discusses, some orgs would mix multiple adoption models, and I expect some people would too (e.g. stable releases at work, every beta on their personal system).
Ideally, we’d work with the PSF to get some questions along those lines added to the annual Python developer survey.
That sounds thoroughly dissatisfied to me, and you’re definitely part of the intended audience for the rolling beta release stream in the revised proposal.
Your original feedback gave me the impression that the lack of pre-built binaries was the only deal-breaker for you, hence the changes to actively encourage them. What’s remaining in the current proposal that would prompt you to stick with the 24 month cycle, even though you’d prefer to upgrade more often than that?
Without the pre-work in Python 3.8 to physically separate the three sets of header files (internal, full CPython API, stable ABI), I actually don’t think we’d be able to do it. As it is though, we could even have a bot that detected changes to the external headers and required that either an ABI break notice be added, or else an explicit “ABI compatible” label be set on the PR.
The draft release announcements in the latest PR hopefully make it clear that it’s only breaks in the full CPython ABI that would require an alpha. ABI compatible additions are fine in a beta release, as they can’t make an existing extension module segfault.
Lack of certainty that all of my preferred 3rd party modules would be available. You say that the proposal is set up to encourage projects to ship binaries, but I remain skeptical. And having to check all my dependencies (including ones I don’t use at the moment, but “might need” - most of my Python use is ad-hoc scripting and data analysis, not nicely defined applications with well-known dependencies) before deciding whether to upgrade is not something I want to do.
The social/support implications of “running a beta”. I know this is subjective, and you want to persuade people otherwise, but I simply don’t like the idea of running a beta version for my main Python interpreter.
I’m conscious that as a package maintainer, I would (even under this proposal!) feel less inclined to support users running the beta stream - so why would I want to run it myself?
To expand on the “as a package maintainer” point a little, you’re proposing having more frequent Python betas than pip releases. And when users report a problem with pip, we quite often will ask them to confirm that the problem exists with the latest pip version. So I’d similarly expect to ask if a problem exists with the latest Python beta (I’m fine with supporting older release versions, less so with betas). So people not willing to upgrade to every beta, could easily end up getting worse support from projects like pip.
BTW, there’s a lot of the above paragraph that I’d word (and think about) very differently if we were talking about stable releases rather than betas (even stable releases every 2 months!) - which is why I think that the social aspects of naming these releases “beta” is more important than you do.
I’m aware these reasons are subjective, and probably don’t seem compelling to you - but as you’re expecting the people running betas to be driven by a “self-selection effect”, I assume that the subjective reasons why people would (or would not) select themselves are useful feedback for you.
But I don’t want to monopolise the discussion here, and this is only my personal opinion, so I’ll offer these thoughts as a reply to your question and leave it at that.
I think the naming aspect matters, I just also think it’s important that we continue to call them betas initially, and these are amongst the reasons for doing so. Your reaction of “We would only support the latest beta release, so if your issue couldn’t be reproduced there, we wouldn’t be interested” is exactly the attitude I believe package maintainers supporting the rolling release stream should adopt (and that was an explicit feature of Steve’s original fast track/slow track proposal as well).
One of the big reasons I want to see us go this way rather than the PEP 602 way is to avoid significantly increasing the number of Python versions that 3rd party library maintainers are expected to support. Instead, I want to only add one, and I want it to be a rolling “you must be running the latest version if you want anyone other than yourself to investigate your bug reports” stream.
I also actively don’t want mere inclusion of a new standard library API in a beta release to trigger the long “Now we’re stuck with it for the next 3-5 years” deprecation cycle, as that would completely destroy the “improve the pre-release design feedback cycle so we don’t need to rely on post-release provisional APIs as heavily” aspect of the proposal. (This is the other big weakness I see in PEP 602: unless we dramatically increase our use of provisional APIs, it doesn’t do a great job of enabling faster design iteration, as we’d still incur the long deprecation period on our API design mistakes. And if we do increase our use of provisional APIs, then we’d be making some of the supportability problems Amber Brown raised in her language summit presentation worse rather than better, and also be exposed to many of the problems that were raised with PEP 598’s incremental feature release proposal)
Under those circumstances, if we don’t call the pre-releases betas, then we’d potentially be creating all sorts of false impressions that we can avoid just by keeping the beta naming scheme. That could potentially change by the time 3.10 rolls around, which is why I think that would be the time to reconsider the naming.
In the meantime, folks using the pre-release versions will genuinely need to be more self-reliant and willing to investigate issues that come up than folks running the stable releases, just as folks running Fedora need to be more change (and breakage) tolerant than those running RHEL or CentOS (or Debian unstable/testing vs Debian stable, or regular Ubuntu vs Ubuntu LTS). However, there are folks happily running Fedora(/non-LTS Ubuntu/Debian unstable) in production (or as their main desktop OS), and most of the time it works fine - you just accept that sometimes it won’t work fine, and blindly upgrading everything right before a critical presentation is probably a bad idea.
Running CPython nightly builds would be akin to the Windows Insider Canary ring
Running all the pre-releases (alpha and beta alike) would be a bit like the Windows Insider Fast ring
Running only the beta releases would be a bit like the Windows Insider Slow ring
Waiting for the stable release candidate would be like waiting for the Windows Insider Release Preview
It’s sounding like you personally would weigh up the pros and cons of the rolling release series and the stable releases, and come down on the side of “latest stable release”, unless and until something came up in the rolling release stream that made you go “I want that enough that I’m going to upgrade to the rolling release stream right now rather than wait until the next stable release”. If no such must-have feature came up, then you’d continue on your way with 3.8.x maintenance updates, and then look at upgrading after 3.9.0rc1 was available.
So given that, I’ll flip my previous question: is shipping Python 3.9.0 in August 2021 (22 months after 3.8.0) rather than in April 2021 (18 months after 3.8.0) the only reason you’d be -1 on at least trying out the pre-release management changes proposed in PEP 605 for the Python 3.9 release series? Or is there some other aspect that you believe would introduce an unmanageable burden on the core development process?
It’s relatively easy to separate those change proposals after all - keeping to the 18 month cadence would just mean starting the 3.9.0 release candidate cycle in February 2021 rather than June. If we did that, then the shift to a 24 month cadence would take place over a couple of release cycles, and could be made contingent on a successful migration to the new pre-release management model:
3.9.0 in April 2021 (18 months after 3.8.0)
3.10.0 in August 2022 (16 months after 3.9.0)
3.11.0 in August 2024 (24 months after 3.10.0)
The most visible external impact that would have is that it would be Ubuntu LTS that consistently got an 18 month old stable Python release, and Debian stable that consistently got a 6 month old one.
I’d be surprised if you were the only one that felt this way, so I figure by discussing this with you, we’re also answering questions that aren’t as readily absorbed in the PEP format (even with the Discussion session mostly structured as an FAQ)