search

Tinche / aiofiles

File support for asyncio
Apache License 2.0
2.62k stars 151 forks source link

Why jumping from v0.8 to v22.0 #144

Closed asgarciap closed 1 year ago

asgarciap commented 1 year ago

My dependency bot just detected the new released version 22.0.1. Is there any reason to jump from 0.8 to 22.0 and why is the version marked as TBC? What does TBC means?

Tinche commented 1 year ago

We switched to CalVer, 22.1.0 means it's the first release of 2022 (using the new scheme).

As for the TBC, I forgot to paste in the release date, which was yesterday. Will fix later.

Tinche commented 1 year ago

I fixed the release date. As for CalVer, I'll let you do your own googling, but you might start here: https://hynek.me/articles/semver-will-not-save-you/

HansBrende commented 1 year ago

@Tinche although semver is not perfect, MAJOR.MINOR is still more appropriate than calver for the majority of projects. As far as I can tell, this project doesn't meet any criterion found in when to use calver. To each their own, but it certainly feels weird.

Anamura commented 1 year ago

same fail to me.. really shocked why version jumped from 0.8.0 to 22.

so funny

bartfeenstra commented 1 year ago

I ran into this change last night. This worries me as (as far as I understand), there is no way to specify a version constraint that lets me pull in compatible updates only, as CalVer simply does not perform the task of communicating compatibility, which SemVer does. Perhaps CalVer is better suited for end-user applications rather than libraries.

TLDR; CalVer for libraries costs me more work as a developer, work that SemVer never required from me

bartfeenstra commented 1 year ago

Actually, I just did some rubber-ducking with a colleague about SemVer versus CalVer, and I have to add some nuance to my previous comment.

Both SemVer and CalVer use a version of x.y[.z][-mod] (z appears optional in CalVer). While x, y, and z have different values and increment following different rules between the two standards, what's common between them is that in each, the relationship between x, y, and z is the same. That still lets us use version constraints rather than specific/explicit/pinned versions when pulling in dependencies.

Tinche commented 1 year ago

The simple fact of the matter is that SemVer communicates developer intent, not compatibility. And even developer intent is very ambiguous - any change has the potential to break users (Python itself has been known to break stuff in minor releases from time to time). Counting on SemVer to ensure you can upgrade seamlessly is a fantasy, I'm afraid.

In both cases you need to pin the exact version you're using and do upgrades mindfully (running your tests and typecheckers after each). But I'm repeating the points of the article I linked.

HansBrende commented 1 year ago

The simple fact of the matter is that SemVer communicates developer intent, not compatibility. And even developer intent is very ambiguous - any change has the potential to break users (Python itself has been known to break stuff in minor releases from time to time). Counting on SemVer to ensure you can upgrade seamlessly is a fantasy, I'm afraid.

@Tinche you're conflating Major/Minor with SemVer. Python is not SemVer. Python is Major/Minor. A Major/Minor release cadence does not imply semantic versioning unless the developer specifically documents it as such.

Disregarding SemVer altogether for a moment, Major/Minor is more appropriate for the vast majority of projects than CalVer. To reiterate my above comment:

this project doesn't meet any criterion found in when to use calver.