It’s absolutely a different way of doing things, but without it, there wouldn’t be a sufficiently clear indication of the cases where we think the rolling stream is going to get a little rough for a month or two.
conda isn’t substantially different from a Linux distro in that regard.
If the mixing of alpha & beta releases proves unworkable in practice, the obvious fallback is to call everything betas, the same as we do today. It would just be unfortunate to perpetuate the situation where upgrading between two consecutive beta releases can cause segfaults due to an extension module being affected by an ABI break. Thus the PEP’s proposal to insert an intervening alpha release as a marker instead.
Bear in mind that only the most recent alpha or beta is ever supported, so trying to encode the specific version in metadata is unnecessary. Once a newer alpha or beta is released, package maintainers should just forget about the previous ones.
I get the intent of wanting to protect users who agree to update Python regularly and then don’t, but we can protect them in other ways. I’d happily go as far as offering updates notifications in the alpha and beta releases of Python itself.
So the version number ordering looks weird, but the important part really is for users choosing Python (“I want the stable release”, “I want the latest prerelease”, “I want the latest release except where the Python team is actively warning me about compatibility concerns”), not for packages to choose themselves.
(And for the one edge case where a user is on a beta but the package has changed to support the newer alpha: presumably an older release of the package supported the older version, and one of the “do I qualify for using the prerelease stream” factors is “I can manage my own dependencies”, which implies that downgrading the package is viable. No doubt people will get this wrong, as they already do today, but I think the expectations are clearer this way.)
Automating this aspect is the rationale for the suggested Python-Requires entry:
Users still on 3.9.0b4 would get the last package version built for that ABI
Users on 3.9.0a5 would get the rebuilt version
Users on 3.9.0b6+ would also get the rebuilt version
I still expect a lot of folks using the rolling releases would just set “–no-binary :all:” and manage their own builds, but even in that case, the very clear “Rebuilds may be required” marker of publishing an alpha instead of a beta should still be useful.
I’m a super strong -1 on this idea, I think it’s trying to be too clever and in the process of doing so makes the entire situation far more confusing than any benefit provided by it.
I’ve read through the PEP twice and don’t feel like I’ve got a solid grasp on how the versioning scheme works at all, which seems problematic to me.
The cadence of every 2 month releases doesn’t actually bother me at all. I just really do not like trying to be cute with the version numbers like this does.
This honestly seems like just a repackaging of the fairly common "X month release cycle, and every Y year(s) one of those is tagged as a LTS, that’s fairly common (Ubuntu does it, Nodejs, etc), except different and weirder to avoid people who want to stick to an LTS release from having to think about the fact they’re on an LTS release. Is there anything fundamentally different in here from “new 3.N release every 2 months, and every 2 years whatever 3.N release falls on that is actually a LTS release”?
Sorry about that! Because there were competing PEPs, there was a combined announcement, and we missed going back to update the individual discussion threads.