Semver versioning

[glennawatson]

https://twitter.com/DavidBoike/status/1178288798238674944?s=19

David pointed out that it'd be good to consider semver as a requirement.

https://twitter.com/adamralph/status/1178298399856177152?s=19

Adam points out Sometimes it may make sense for a lib to not follow SemVer. E.g. when it makes more sense to follow the majorminor of an upstream package. I think we need to be careful about baking in absolute "SemVer is good" assumptions into product quality assessment.

[glennawatson]

I personally think there should be adoption of some version policy ideally semver 2.

[DavidBoike]

Even then SemVer should only be one positive indicator of adoptability. Never a rigid test. One example: I know at times the RabbitMQ client has been known to introduce a breaking change in a minor release, but I would be frustrated if enterprises refused to use RabbitMQ solely on the basis of this maturity model stuff ranking it low due to SemVer. And I would be HORRIFIED if an enterprise would not adopt NServiceBus because NServiceBus uses (and effectively insulated you from) the RabbitMQ client and the transitive dependency is not highly ranked.

[haacked]

As the former maintainer of SemVer I'd like to chime in here that it's impossible to have a rigid test for SemVer. You can perhaps have a rigid test for binary compatibility, but that's about it. Even changing internals can break someone somewhere.

The key thing about SemVer is it's about communicating intentions and risk. If you make a change that your analytics tell you might break 1 app in a million, I think you're fine calling it a minor release.

So I'm supportive of adopting SemVer as a versioning policy, but it's important that it's not a set of strict shackles but a guideline for communicating intentions and risk.

• Major - we expect this will break you
• Minor - This probably won't break you
• Patch - This most likely won't break you, so we hope.

😄