sbt-version-policy VS unity

In the Scala ecosystem, MiMa [1] has been in widespread use for years. It automatically checks compatibility for the binary API of a library. Every library with any amount of success uses it. One could say it's the foundation of a stable ecosystem. We also have sbt-version-policy [2] to set it up with minimal configuration (and directly relate it to SemVer).

More recently, we got tasty-mima [3], which checks compatibility at the type system level, rather than the binary level.

[1] https://github.com/lightbend/mima

[2] https://github.com/scalacenter/sbt-version-policy

[3] https://github.com/scalacenter/tasty-mima

Can you compare/contrast to https://github.com/scalacenter/sbt-version-policy ?

This is more a coordination problem, semver doesn't really matter here, except as a good enough standard or guardrail for most. It's going to get broken from time to time, and that is fine.

The CUE Unity project is an interesting take on how to "solve" the bigger issue of breaking changes or regressions.

https://github.com/cue-unity/unity

Basically, the idea is that users can register their project, tests, or benchmarks in Unity. The project maintainers can then test new code against these projects before releasing, or even before pushing a commit, because a regression is found for example. This works by injecting the version (or local code) into the dependency management system. For CUE, this is a `go mod edit`, or setting up the environment with the cli at version / local. How this is set up and managed isn't as important as getting the process in place and making it an easy workflow for both sides. Hence why I call it a coordination problem.