sbt-version-policy sometimes makes unnecessary major/minor version bumps

[rtyley]

It's worth noting that unnecessary major/minor version bumps are way better than missed major/minor version bumps, however they can still be surprising, distracting, and sometimes inconvenient.

Debugging version bumps

Debugging version bumps from dependency updates can be done with the versionPolicyReportDependencyIssues sbt command, however, see the workaround in:

• versionPolicyReportDependencyIssues requires versionPolicyIntention to be set scalacenter/sbt-version-policy#229

Note that if you're trying to debug this just after a release (eg release v4.0.0), and you want to know why the jump occurred, you'll need to git checkout the previous commit (eg git checkout v4.0.0^) before running versionPolicyReportDependencyIssues (the command always defaults to comparing your code to the version based on what's in version.sbt).

Causes

There could be many causes for unnecessary major/minor version bumps, however I'm currently only aware of one that we've been encountering:

Dependencies that use abnormal version-numbering styles, like 4.1.115.Final

Examples:

• chore(deps): AWS dependency updates etag-caching#20 (comment)
• Update aws sdk to fix netty vulnerability simple-configuration#100 (comment)

For example, io.netty libraries use a version scheme like 4.1.115.Final, with a .Final suffix. This is not understood by sbt-version-policy, and so it assumes its a binary incompatible change. As explained in scalacenter/sbt-version-policy#139:

sbt-version-policy currently relies on coursier versions for parsing version numbers and correctly identify tags. If coursier doesn't support the version naming scheme that a dependency uses, we get false positives from versionPolicyReportDependencyIssues.

sbt-version-policy has a solution for this in the versionPolicyModuleVersionExtractor setting, added with scalacenter/sbt-version-policy#140 - but this isn't ideal for us at the Guardian. The setting lets us add custom version-number-parsing code, but rolling this out over our ~48 Scala libraries, and keeping that code up-to-date in all those repos would be tiresome. I think we need a solution centralised at an organisation level (ie within gha-scala-library-release-workflow), or within sbt-version-policy itself.