PEP 2026 – Calendar versioning for Python | Hacker News Reader

PEP 2026 – Calendar versioning for Python

peps.python.org

20 pointsBerislavLopac10 comments

I guess I never noticed that they release around once a year.

https://devguide.python.org/versions/

I guess with project of this importance, one cannot have anything else than fixed release date, even if the scope is dynamic. A bit like Olympic Games hosts are decided several years in advance (Salt Lake City 2034).

I think this is a very cool change

also lol:

  > The 3.14 release cycle must go ahead because: [pi].

So... what happens in 2126?

I suppose we will have python4 by then.

3.126.0

This is covered in the PEP:

> In the year 2100, the minor will be 2100-2000 = 100, therefore the version will be 3.100.0.

If they go through the work of changing the version scheme, I think they should adopt SemVer instead. This CalVer thing is nice for human users for the tasks they listed, however SemVer holds the advantage for machine-run dependency compatibility management. And I'd argue version numbers in general are used more by people for compatibility than release scheduling.

Personally, it is more often that I look to version numbers to gauge compatibility, than any kind of temporal info.

SemVer is over promised and an under delivered scheme. There’s lots of literature about the difficulty about what “compatibility” means.

They address that in the PEP.

It would basically mean a new major version every year as they remove things that have been depreciated.

Which isn’t really that useful.

Semver is best suited to projects that can afford to make deliberate backwards-compatibility breaks for the sake of facilitating future development, and bundle those breaks together.

Python tried that once 16 or so years ago, depending on how you count (and, frankly, didn't break enough things) - and everyone is still bitter about it.

Reply on news.ycombinator.com