MiMa 1.2.1 is a follow-up for 1.2.0 from 10 days ago, but not a small one.
@sjrd pointed out an old transitivity issue in MiMa’s model:
- changing
def f: Atoprivate[p] def f: Ais allowed, because it stays public in bytecode - deleting
private[p] def f: Ais allowed, because MiMa considers it non-public
If a library author updates mimaPreviousArtifacts between steps 1 and 2, MiMa never issues a warning, even though code compiled against the first version will break.
New warning before MiMa stops checking a definition
MiMa 1.2.1 introduces new warnings for changes that will prevent future checks, like the one above.
These new warnings should not be filtered (silenced), otherwise we are in the same situation as before. Instead, there is a new setting mimaBinaryApi:
mimaBinaryApi += BinaryApi.keep[MethodNoLongerCheckedProblem]("p.C.f()A")
This tells MiMa to continue checking changes to f as if it was public API, so later changes are detected.
Fixes for false negatives and false positives
The new release contains various fixes for false negatives and false positives.
Potentially controversial: MiMa no longer reports any changes to the compiler-generated static accessor methods for object members. These accessors exist for Java interop, which is by design out of scope for MiMa. The README was updated to clarify this
MiMa checks your binary API as Scala code sees it
There might be people using MiMa for APIs written in Scala for Java consumption. That use case was never really supported and there are multiple reasons why it’s unsafe. But we could consider adding an opt-in best-effort Java mode.
Full release notes: Release 1.2.1 · scala-garden/mima · GitHub