Adopt Effver

[almarklein]

This is a proposal to adopt EffVer for versioning. Learned about this on Euroscipy: https://jacobtomlinson.dev/effver/.
We kinda used SemVer until now, except we're still in the 0.x yolo fase, so it doesn't really matter/count.

My short summary

Like SemVer, EffVer adds semantics to the numbers, but in a different way: where SemVer promises something about the kind of changes, depending on what number is bumped, in EffVer it says something about the expected amount of work for downstream devs. The idea is that it gives a more honest signal to downstream devs.

For more details, please follow the link above, and maybe semver-will-not-save-you to understand why SemVer often does not live up to its promise.

A practical comparison

	SemVer	EffVer
bugfix	x.y.Z	x.y.Z
new feature (but does not break anything)	x.Y.z	x.y.Z
small backwards incompatibilty	X.y.z	x.Y.z
major changes to API	X.y.z	X.y.z

So downstream libs should typically pin to x.y in EffVer.

My take

• SemVer is nice for projects that actually support multiple release branches (e.g. Python 2.x and Python 3.x).
• For projects that release more "linearly", EffVer makes more sense.
• For applications CalVer makese sens IMO (anything that does not have an API.

Special note for wgpu-py

When we update wgpu-native, I always try to isolate this into a new release, so that users can chose between two versions that are the same except for the version of wgpu-native. With EffVer I can pick whether to bump x, y, or z, depending on e.g. the amount of shader code that people will need to update.

[almarklein]

I extended the notes above. @Korijn what do you think?

[Korijn]

I don't really have a strong opinion on this particular distinction. :) I feel like many developers already interpret semver in the effver way, perhaps accidentally. I could be practicing effver without realizing it.