Remember that the package has made a new release with the >=3.14 requirement at a time when the latest Python version is 3.14.0a1. Why would it be helpful to avoid that release? There are no runtimes in existence that can install it if the requirement doesn’t include prereleases.
The “right” way here is for the package to make a release with a >=3.14.0a1 requirement. Which technically works, but is against the spirit of the metadata (as we agree), and gives a false sense of precision (if the requirement was >=3.14.0b2 and the user has b1… should we really backtrack?).
I feel as though we must be at cross purposes, but I am failing to put my finger on how.
Suppose as a diligent package maintainer I release my-package 3.0 that requires 3.13 language features, and then later I release my-package 4.0 that requires 3.14 language features. Then suppose someone using python 3.13 requires my-package: surely we agree that it is useful to backtrack to version 3?
The question is whether the same backtracking is useful for someone using python 3.14.0a1.
If we decided that >=3.14 was not compatible 3.14.0a1, then it would be useful - just as it is useful because >=3.14 is not compatible with 3.13.
It might be that I’m inferring more of the user’s intent from the fact that they’re on a prerelease CPython?
Backtracking is to play it safe, and increase the likelihood of getting a working install. Prerelease users shouldn’t care about that.
But also, if 3.14 isn’t out yet, then it would be impossible to install a package with Requires-Python>=3.14. That isn’t helpful for anyone, which is why I say it’s not worth us deciding to treat them this way.
I do agree with most of what you are saying. I was not really expecting this sub-topic to get to a fourth reply, it is probably getting more space than it deserves.
But I think that specifically your argument about backtracking is circular: you can only conclude that this backtracking is a bad idea if you take as a premise the answer you want to reach.
Given how quickly we seem to have reached a consensus, in principle, on the semantics I’m happy to go ahead and draft a pre-PEP.
It’s worth noting, as @pf_moore points out, that this would likely go beyond a packaging PEP. It would essentially lock the Python language into version numbers that always follow the X.Y format, where X and Y are numbers that strictly increase (as a pair, that is).
A consequence of this is that it would rule out some forms of CalVer, which I know has been a topic of discussion.
I assumed we’re already locked into that by some specification somewhere. If not, it’s certainly been explicitly stated as part of the compatibility guarantees of moving from X.Y.Z to X.Y.(Z+1) (there will be no language/syntax changes).
In reality, as long as sys.version_info[:3] continues to be a tuple of numbers, and increase each release, there won’t be a problem. It would be a weird change in version format that violated that principle (and it would break a lot of code that checked that value at runtime).
In reality, as long as sys.version_info[:3] continues to be a tuple of numbers, and increase each release, there won’t be a problem. It would be a weird change in version format that violated that principle (and it would break a lot of code that checked that value at runtime).
Well, if it’s the language version it would need to be sys.version_info[:2] , e.g. (3, 13), (3, 14), etc. my point was that this proposal would prevent the language version from becoming 3 parts or more (didn’t mean anything about the length of the digits).
No it wouldn’t, it would just mean there’d be one more thing that has to be updated in order for packages to specify a third version and still be within specification.
The language version would become three parts at a particular time, and prior to that, it wasn’t. So nobody is “correctly” using a three part language version right now and won’t be broken, and when they start then we’ll have already updated the spec (and hopefully the tools).
That would still be fine as that would make the 3rd component the bugfix version as Python has an annual release cadence. Regardless, PEP 2026 – Calendar versioning for Python | peps.python.org isn’t proposing it and it that PEP gets rejected I don’t see us changing the format any time soon.
Besides, this whole topic is about updating a spec, so implicitly we seem okay with changing things if necessary.
