Proposal: SemVer approach to default ABI changes

[jamadden]

I'd like to suggest that we use the first digit of the version number in a SemVer compatible way. In addition to direct user-facing breakages, it should be bumped when the default ABI changes on at least one supported platform/python version.

The idea is to help avoid situations such as #178.

This would let downstream projects like gevent that extend or embed greenlet to place an upper bound on their supported greenlet versions. For example, gevent would would have written greenlet >= 0.4.16, < 1.0. Instead of releasing 0.4.17, because of the ABI change, we would have released 1.0.

This isn't a panacea because the ABI can be changed at compile time without changing the version, but it might help.

Another issue, of course, is false positives. Suppose greenlet 2.0 adds support for some obscure platform that requires an ABI change but only on that platform. If greenlet 2.0 also includes some additional features that don't break ABI or API, downstream packagers would have to update their version pins to take advantage of those features, even if they don't support that obscure platform, potentially locking end users out of being able to use those features (easily).

There are workarounds, like forcing particular versions of packages to be installed and ignoring version pins, but those are not something the average user should be expected to deal with (and pip is moving to make that harder, not easier).

That seems like a small, acceptable risk to me.

[jonringer]

SemVer also states that versions below 1 are not "stable", and bumping the middle number is considered a breaking change. https://semver.org/#spec-item-4

This would be expressed as, greenlet >= 0.4.16, < 0.5 or greenlet ~= 0.4.16