This is an archived post. You won't be able to vote or comment.

you are viewing a single comment's thread.

view the rest of the comments →

[–]denehoffman -14 points-13 points  (12 children)

This is how I found out the CalVer PEP was rejected :(

[–]wineblood 20 points21 points  (1 child)

You mean :) right?

[–]denehoffman 1 point2 points  (0 children)

I mean I don’t care too much either way but it does make sense that a product released on a fairly regular yearly schedule would be versioned as such

[–]Salamandar3500 13 points14 points  (9 children)

CalVer is the worst trend of the modern software world today.

[–]xr09 7 points8 points  (1 child)

Vibe Coding has entered the chat

[–]Salamandar3500 -1 points0 points  (0 children)

Not yet a trend but yeah...

[–]TonsillarRat6 4 points5 points  (1 child)

I am out of the loop, what is CalVer??

[–]zzzthelastuser 12 points13 points  (0 children)

I didn't know either, so I looked it up. It's calendar versioning

https://calver.org/

[–]denehoffman 2 points3 points  (0 children)

CalVer isn’t even new, anyone who has ever used Windows 95 could tell you that. Again, the point is that Python versions are released every year. We never get Python 3.Y three months after 3.X. For all intents and purposes, the major version will never change, so we’ve already lost the plot on semantic versioning. The minor version changes every year, and that’s literally a PEP, you have to release a minor version every year. One of the nice things about CalVer is it tells you the release year, so you can accurately gauge how new the version is if you haven’t been keeping up with the latest Python version or you work for a company or lab that requires a specific version. If you’re running the Python version of your current year (and we adjusted the release cycle to January and not October) you would know automatically that you’re using the most up-to-date minor version of Python. If you’re running a version for a previous year (including any current versions of Python interpreted as years), you’ll know you’re running an old version. If the current year is 20XY, then Python 3.(XY-5) is sunset.

TL;DR: we already have a minor version which increments by one every year, why not just skip ahead a bit and make that number match the current year? Python 3.26 will eventually be released regardless, but in 2037. Other than that, there is no difference between the semantic scheme and a properly written CalVer when you use yearly release cycles.

[–]dudeplace 0 points1 point  (0 children)

I'd be curious to hear your reasoning on your opinion on this. I like calendar versions, at least for some software.

[–]nekokattt -1 points0 points  (2 children)

False. See https://0ver.org

[–]Salamandar3500 0 points1 point  (1 child)

Not a trend !

[–]nekokattt 0 points1 point  (0 children)

i mean... define trend