I think it would help. Pip uses two-digit year versions, I think people are used to seeing the year as a two-digit version number.
Yes, absolutely, the more important information is the actual changelog.
I still think aligning the version number with the year is a small step to help people understand the release process and cadence.
I don’t see a downside to making this change. The main argument against seems to be, “this won’t change enough to be worth it.” A small change can still be a good change.
I’ll just add (without reading any context of this thread) users regulary confuse pip’s YY.N.Z release number to be SemVer, and complain when YY.N+1 breaks something, and ask why pip didn’t wait till YY+1.
At least PyCharm, and ECMAScript use a four-letter year, which makes it obvious. Black and Ubuntu don’t, but I was aware that they use CalVer. (Edit: Although I only learned about Ubuntu using the year as part of the version after using it for a few years.) I’m not sure I would consider C using CalVer, since newer versions don’t have higher numbers (e.g. C89 being older than C11). I wasn’t aware that pip used CalVar, and I kind of thought it used a major.minor scheme. Two-letter years are not obvious, unfortunately. Especially not if they are not used as the major component of a version number.
That and having to explain the mixed versioning schemes for the next 5 years. Although, the more I think about it, the more I realise that my aversion is coming from simultaneous versioning schemes (like Windows 11 being 10.0.22621 or OpenJDK 17 having the version 1.6.0) rather than just skipping a few numbers – what makes those versioning schemes confusing doesn’t apply to this PEP.
That is a fair point, but the proposed 3.YY versioning scheme doesn’t solve this - it just looks like SemVer where the minor version incidentally is the same as the year in which it was released, which you will only know if you are fairly informed about the Python release process in the first place. CalVer is only really obvious to Average Joe Dev if in the form YYYY.MM or other forms that include a four-digit year.
The change feels like a lot of churn for minimal gain and the comments here show that you can’t interpret the release version without very specific Python ecosystem knowledge (off by one error, etc.).
But I would like to stress that I think the high number of people that I see expressing their surprise at pip using CalVer shows how hard it is to recognize CalVer with only two digits. Many of the people commenting and liking those comments are people I see regularly commenting on this site and who I would expect to have a lot of knowledge about the Python ecosystem. (I also didn’t know this myself). I would not be in favour of this proposal with only double digits as I think in that form the benefit of the change is even lower and doesn’t weigh up to the churn and questions people would have about the versioning scheme.
I’m personally highly in favor of CalVer but uncomfortable with how this proposal binds it together with a final decision to freeze the major version at 3. I understand that ever since the previous transition there’s been a firm opposition to moving from 3 to 4 but I believe having that option available is a good thing. It is possible that in the distant future the prevailing mood might weaken and some fundamental change in the language might necessitate making the switch (whether it’s making no-GIL build default or melding typing with runtime or supporting whatever quantum plasma hyper-AI thingamajig that might become mainstream in computing in the next 5-15 years).
Adopting this PEP would mean that in that eventuality Python would have to go from e.g. v3.35 to v4.36 which to me looks beyond awkward and is an argument in favor of other CalVer patterns such as vYY or vYYYY. This awkwardness would likely mean that any future change to a major version number (however unlikely it might be) would also have to be paired with another versioning scheme change.
I’m +0.5 on CalVer, but I don’t think 3.26 is the way to go. It is not at all clear that this is CalVer, it looks like a normal version number (so users would still make the assumption of SemVer and not breaking backwards compatibility). 26.0 might be more so, while 2026.0 would be extremely obvious, and it would communicate clearly that Python does not do SemVer.
I disagree that Python 3 is the brand. After all, we’re on discuss.python.org, not discuss.python3.org (even though the latter is owned by the PSF according to whois info; it only seems to host mail.) The phrase “Python 3” only appears once on the PyCon US 2024 schedule, and only as part of the 3.13 version number (you’d think it would see top billing as the brand). I think that PEP 394 is due for an update that would require distributors to adopt python == python3, since Python 2 is dead, and you have to try real hard to end up with it on many systems (Debian stable, Ubuntu 24.04, openSUSE Tumbleweed don’t have any package for it; Fedora seems to have a package for some reason), which means that many systems default to python == command not found. And at the same time, the PEP could also say that python3 is an evergreen alias as well, i.e. python == python3 == python2026.
While I’m at best lukewarm towards this PEP, I don’t see the hypothetical situation you describe as really much of an issue. This is exactly how protobuf does it for example – their minor version (not actually CalVer-bound) – is the feature level, and the major version indicates breaking changes (and moves independently per language that protobuf offers bindings for).
I do like the idea of CalVer but I think 3.26 does not solve anything. I would prefer CalVer with YYYY but the PEP already rejected it for being a breaking change.
I had no idea Ubuntu/pip/black use CalVer because their YY scheme is ambiguous while one look at PyCharm’s was enough for me to realise it’s CalVer. Python switching to 3.YY would carry over all the same problems.
I also do not think python3 is a brand and so I don’t think there’s a need to keep it at 3. It’s just a version number. Python on windows doesn’t even provide a python3 command.
Thanks @hugovk for the PEP, very well written and with the right amount of details. I overall support the PEP as it introduces more clarity in the versioning of Python without being too disruptive as things stand.
If we mandate the release year in the versioning scheme, the only big limitation that I see is if we release multiple major releases in a given year.
If we do 2 releases in 2026 these can be versioned 3.26 and 3.26-2 (with subsequent 3.26.1 3.26-2.1) where the “-2” stands for the second release of that year (and not the month)
The proposal is not convincing me at this point. While the purported benefit of the change seems to be all about communication and clarity, all the considered alternatives are just different versioning schemes. I see an unchallenged assumption that changing the versioning scheme is an effective solution at attacking the stated problem.
Can we consider alternative proposals in the “communicating more clearly” field that are not only about versioning? Just the first things that come to my mind:
I’m looking at the Python 3.12 release page. This is the first one you get by the Python.org home page, and one of the first results on DuckDuckGo. There is no mention of either the yearly release schedule, or the planned EOL. There is a link to PEP 693 at the bottom of the page detailing the release schedule, but it’s a bit hard to find.
What’s New in Python 3.12 also links to PEP 693, but the page content itself does not prominently feature the idea that it’s supposed to be the “2023 Python” nor the EOL.
The Python documentation home page could be a good candidate for mentioning the year associated with the release (again, some sort of “2023 Python” mention would help, with a link to the schedule).
sys.version, and the banner you get when you launch Python, could possibly be another place to mention the year, although there are pros and cons.
Ad-hoc documentation and informative pages, more prominent than the release schedule PEPs.
Public facing announcements and social media posts and so on.
These would work in the direction of making the information “easy to see” as PEP 2026 intends to do.
@hugovk A minor point I realised the PEP may as well mention after seeing https://thenewstack.io/python-mulls-a-change-in-version-numbering/ misunderstand (or, more accurately, report others misunderstanding it without correcting the misunderstanding): the fact the X.YY.Z CalVer based number isn’t locked to a specific number of digits in any of the fields.
There’s no Y2K equivalent here since 3.100.0 is a valid future release number (we have no reason to go down the C11 vs C89 path), but that may not be obvious to folks that didn’t see the 4.0 vs 3.10 discussions a few years ago.
I’d assumed this wasn’t something we were going to worry about, but if it is, then I will say that I don’t think it will be particularly obvious that Python 3.112 was released in 2112…
Lest people think I’m mocking, I do actually like this PEP, but it’s a minor aesthetic thing and I won’t be heartbroken if it fails. Maintaining several scientific Python packages, I’m extremely aware of end-of-life and deprecation schedules for Python, numpy, and most of the packages addressed by SPEC0. This PEP will drop my mental SUB ops by one a few times a year, but I’m pretty much always consulting a table anyway.
I’m +0 in the PEP, but would be +1 for 3.YYYY.M or YYYY.N.M. I don’t think the confusion about where 3.15.-3.25 went will last (Python will hopefully last long enough that the gap will be viewed as a historical quirk).
I like the full digits of 3.YYYY.M because it makes what is going on obvious. I’m not so concerned about breakage if we have a longer transition. Same goes for YYYY.N.M, but it also makes us more explicit that we won’t do another 2->3.
