A tool for catching binary incompatibility in Scala
Most MiMa checks (DirectMissingMethod
, IncompatibleResultType
, IncompatibleMethType
, etc) are against the method descriptor
, which is the "raw" type signature, without any information about generic parameters.
The IncompatibleSignature
check compares the Signature
, which includes the full signature including generic parameters. This can catch real incompatibilities, but also sometimes triggers for a change in generics that
would not in fact cause problems at run time. Notably, it will warn when updating your project to scala 2.12.9+ or 2.13.1+, see #423 ("Signature checks fail using value classes & upgrading to 2.12.9+ or 2.13.1+") for details.
This check is now disabled by default. You can opt-in to it by setting:
ThisBuild / mimaReportSignatureProblems := true
IncompatibleSignatureProblem
message & link to the docs in the README. #435 by @raboof(Failed release. Details in the release tracking issue: #454)
This release of MiMa uses sbt 1.3, which isn't forward-compatible with previous versions of sbt 1 (e.g. sbt 1.2.8). That means your build must on sbt 1.3 in order for it to use MiMa 0.6.1+. The step-wise approach would be to upgrade the build to sbt 1.3 first and then upgrade it to use MiMa 0.6.1.
This release of MiMa is built against the scala compiler 2.12.10, which allows it to be used within sbt 1.3.1+ (fixes #389).
The last 2 highlighted changes fix the fact that previously some DirectMissingMethodProblem
s were incorrectly reported as IncompatibleResultTypeProblem
/IncompatibleMethTypeProblem
and vice-versa. If you have added filters for such cases to your project, when upgrading to mima 0.6.0 you might have to update those to filter out DirectMissingMethodProblem
instead (example: https://github.com/akka/akka-http/pull/2656/files).
The 0.4.0 release of MiMa included a breaking change that sought to help users discover when they were running mimaReportBinaryIssues
but hadn't configured mimaPreviousArtifacts
.
Unfortunately, that had a larger impact than expected, quickly brought to light thanks to the PRs sent by the ScalaSteward (see the ScalaSteward annoucement blog post!).
With the release of MiMa 0.5.0 we've been able to solve the initial issue by being able to differentiate when mimaPreviousArtifacts
was unset by the user and when it was purposely set to the empty set (for instance, if their library cross-builds to Scala 2.13 but hasn't yet been released for Scala 2.13).
Additionally the README has been fully refreshed and now gives better guidance, in particular see the Setting different mimaPreviousArtifacts
and Make mimaReportBinaryIssues
not fail sections, the latter of which details how use 0.4.0's mimaFailOnNoPrevious
setting to handle breakages.
#328/#334/#338
As of v0.4.0 mimaReportBinaryIssues
will, by default, fail if mimaPreviousArtifacts
is empty, to avoid users thinking they're checking binary-compatibility when they aren't.
You may need to apply one of the following to mitigate this change:
mimaPreviousArtifacts
for all the projects that should be checking their binary compatibilitymimaFailOnNoPrevious := false
on specific projects that want to opt-out (alternatively disablePlugins(MimaPlugin)
)mimaFailOnNoPrevious in ThisBuild := false
, which disables it build-wide, effectively reverting back to the previous behaviourhttps://github.com/lightbend/mima/issues/263 / https://github.com/lightbend/mima/pull/289
As of v0.4.0 MiMa no longer supports sbt 0.13 and is only available for sbt 1.x. We encourage you to update to sbt 1.x, and until that time use keep using MiMa v0.3.0.
https://github.com/lightbend/mima/issues/269 / https://github.com/lightbend/mima/pull/272
Support for Scala 2.10 has also been dropping, meaning you should continue to use MiMa v0.3.0 to verify binary compatibility of a Scala 2.10 project.
https://github.com/lightbend/mima/issues/248 / https://github.com/lightbend/mima/pull/272
This release introduces a new problem type, the IncompatibleSignatureProblem
. This problem is reported when a method's erased signature has remained the same, but its full type signature has changed. Such a change is not always binary incompatible, but typically worthwhile to manually investigate and explicitly confirm. You can exclude all such problems with a ProblemFilters.exclude[IncompatibleSignatureProblem]("*")
.
This change also fixes a problem where IncompatibleResultTypeProblem
instances were missed. This means that this upgrade may require adding filters for old, but previously undetected, incompatibilities.
https://github.com/lightbend/mima/issues/40 / https://github.com/lightbend/mima/pull/299
@varargs
mimaPreviousArtifacts
with dots in their nameFor full details see the 0.4.0 milestone and/or the 0.3.0...0.4.0 changelog.
Bumped to 0.3.0 because of the CLI removal.
https://github.com/lightbend/migration-manager/compare/0.2.0...0.3.0