CalVer: Why?

[vaindil]

I posted this comment on the PR but figured I should make a new issue for it since the PR is old.

Why was the change to CalVer instead of SemVer made? What's wrong with semver? Are the discussions that led to this change available anywhere for users to read?

[pfmoore]

We never used SemVer, as that implies backward compatibility guarantees that we didn't give (and weren't willing to). But people kept assuming we did and complaining about breakage. So changing to CalVer made it more obvious that we don't use SemVer.

Also, it's not a case of "what's wrong with SemVer" - we simply didn't want to use it, and CalVer suits our release process, as we release on scheduled dates, not based on feature sets.

There really wasn't any more discussion than that. And for clarity, no, we are not looking for arguments that we should use SemVer.

[vaindil]

There are arguments for each, I'm not trying to change anyone's mind. Can you point me to the announcement issue or wherever it was that discussion happened? I'd like to read what others had to say.

[pfmoore]

As I said, only #5324 really. Maybe a bit of internal conversation where we all agreed calver suited us, I honestly don't recall.

[pradyunsg]

Are the discussions that led to this change available anywhere for users to read?

Nope. This came up in an internal conversation (an email thread) after 10.0 while discussing the delays we had for pip 10 -- the thread was called "Releases after pip 10".

Why was the change to CalVer [snip] made?

I'd like to think CalVer was a natural consequence once we decided that we'd adopt a 3 month cadence and a stricter "keep the master ready for release" model.

CalVer is a good fit for our process now. We can communicate our deprecation policy more clearly, not make users think we follow a different versioning scheme (to the extent possible), the release cycle is predictable for users and the maintainers don't try to make releases "feature releases" like we did with pip 10 (which caused some delay).

[0bsearch]

I know that PyPA is not seeking for community feedback on such topics and decisions made internally, but in case this will ever be discussed again, please, consider couple of simple ideas:

• release schedule and release management may not interfere with product versioning. Keeping releases on schedule (and 3 months is ~perfect, IMO) doesn't matter that you can't live with semver
• semver is made for clean interface. PyPA is working on infra tools for whole python — hard to say what can be more valuable than expected API changes
• if it's easier for team to have version names tied up to release date — you still can keep compliance with semver by just merging YY + 0M

[dstufft]

I'm going to close this, I don't think there's anything actionable on this issue beyond the answers that Paul and Pradyun already gave.

[dlamblin]

Versions 18.0, 18.1, 19.0 and 19.0.1 don't tell those users that didn't read the release notes that this is following calendar based versioning. Seems like you've missed the mark on accomplishing your stated purpose.

[lock]

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.