> Given a version cryptography X.Y.Z,
> - X.Y is a decimal number that is incremented for potentially-backwards-incompatible releases.
> - - This increases like a standard decimal. In other words, 0.9 is the ninth release, and 1.0 is the tenth (not 0.10). The dividing decimal point can effectively be ignored.
> - Z is an integer that is incremented for backward-compatible releases.
The system has since changed, but it continues not to be semantic versioning. (It’s effectively the same, in fact, but protects against dependents who think it is semantic.)
By that scheme, it was already a “major” (signifying potential backwards-incompatibility) release.
[1]: https://cryptography.io/en/latest/api-stability.html#previou...
Because the build toolchain is "visible", that is, pip isn't just downloading a prebuilt binary every time, I think breaking changes that could cause CI systems or user installs to fail is part of the API contract. Think of what major distributions or software packages do when they want to deprecate support for certain platforms - those are major bumps that typically only occur on incrementing the most significant component of the version.
Hypothetical: suppose the the authors changed setup.py so that it only built on Red Hat Enterprise Linux(tm) version 6. Again, they could do that, it wouldn't change the runtime API. And on all other distributions or installers, it would error.
Would that be a major semver change? Of course it would be. The API contract has to include everything from packaging to use.
I wouldn’t want to force any particular versioning scheme on any particular developer, but maybe the “SemVer façade” versioning scheme they switched to is the best compromise. It has defensive value, at least.
Then again, PEP 440 has nothing to say about the semantics of versioning, only requiring:
[N!]N(.N)*[{a|b|rc}N][.postN][.devN]
PyPA themselves describe various expected versioning schemes, but listing Semantic as preferred[1]. If I squint, I can fit `cryptography`’s previous scheme into “Hybrid”. The biggest lesson I take from this is that if your version scheme isn’t SemVer, work hard to make it look obviously different from SemVer.[1]: https://packaging.python.org/guides/distributing-packages-us...
I can’t think of a clean alternative other than coming full-circle back to the “developer advocacy” solution, with its clear problems. Someone smarter than I am probably has it in the palm of their hand, though.