4 ms·
PEP 2026 – Calendar versioning for Python
- xd1936 2y agoI guess I never noticed that they release around once a year. https://devguide.python.org/versions/ https://devguide.python.org/versions/
- playingalong 2y agoI 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).
- cozzyd 2y agoSo... what happens in 2126? I suppose we will have python4 by then.
- tgum 2y agoI think this is a very cool change also lol: > The 3.14 release cycle must go ahead because: [pi].
- RadiozRadioz 2y agoIf 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.
- spott 2y agoThey 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.
- martinky24 2y agoSemVer is over promised and an under delivered scheme. There’s lots of literature about the difficulty about what “compatibility” means.
- zahlman 2y agoSemver 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.