0.8.1

Enhancements

• Resolve ambiguity introduced by JDK 14 #556 by @SethTisue
• Fix error message #555 by @xuwei-k
• Extract andClose #553 by @dwijnand
• Close classpath directory after listing #552 by @raboof
• Use sbt (1.0's!) dependencyResolution #551 by @dwijnand
• Make Logging public again #549 by @dwijnand
• Bunch of little readme tweaks #546 by @SethTisue

Updates

• Update coursier to 2.0.3 #565 by @scala-steward
• Update munit to 0.7.14 #563 by @scala-steward
• Update sbt to 1.4.0 #561 by @scala-steward

0.8.0

New features

• Catch binary-incompatible method overriding in traits #541 by @dwijnand

Enhancements

• Use CoursierDependencyResolution rather than IvyDependencyResolution #508 by @alexarchambault
• Make DependencyResolution configurable #509 by @alexarchambault
• Don't normalize names #510 by @alexarchambault
• Parse signatures to avoid false positives #505 by @raboof
• Fast-fail on unsupported Scala versions #486 by @dwijnand
• Cut dependency on scala-compiler and scala-reflect #495 by @dwijnand
• Replace sys.exit(-1) with sys.error(msg) #490 by @htmldoug

For full details see the milestone and/or the changelog.

0.7.0

Features

• Checking generic signatures is now opt-in. #471

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

Improvements

• Improve problem reporting (#475), specifically, it now:
  • logs at the appropriate log level (warn/error, if there are problems/fatal problems)
  • includes the version of the artifact compared against
  • includes the number of filtered out problems

Bugfixes

• Fix a regression in how version filtered are... filtered. #468

Other changes

• Drop Bintray, switch releasing the plugin to Maven Central. #469

For full details see the milestone and/or the changelog.

0.6.4

Bugfixes

• Fix a regression in problem identification, since 0.6.1 a case of IncompatibleResultTypeProblems were being reported as DirectMissingMethodProblem. #459 / #460 by @raboof (thank you!)

For full details see the milestone and/or the changelog.

0.6.3

Bugfixes

• Fix a false negative when removing all method implementations from a trait (with results in the loss of the trait's "initialisation" method, which is binary incompatible). #426 / #448 (kindly reported by @travisbrown)

Other improvements

• Clarify the IncompatibleSignatureProblem message & link to the docs in the README. #435 by @raboof
• Test infra: run the functional tests, to ensure they're correct. Motivated by the false negative in #426. #427 / #444
• Restore sbt 1.2.8 support. #453
• Lots and lots of cleanup and refactoring. See the entire changelog details.

For full details see the milestone and/or the changelog.

0.6.2

(Failed release. Details in the release tracking issue: #454)

0.6.1

Breaking change

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.

Hotfix

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).

For full details see the milestone and/or the changelog.

0.6.0

• Correctly display static methods #371
• Ignore when the first constructor parameter is dropped from the signature #378
• Removed overloads are missing, not incompatible #362
• Verify all overloads for result types and signatures #345

Migration notes

The last 2 highlighted changes fix the fact that previously some DirectMissingMethodProblems 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).

0.5.0

Fixing the impact of 0.4.0's breaking change

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

Additional improvements

• Fix resolving previous artifacts that defined their Scala version suffix. #327/#329

For full details see the milestone and/or the changelog.

0.4.0

Breaking changes

When mimaPreviousArtifacts is not set, default mimaReportBinaryIssues to fail

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:

• set mimaPreviousArtifacts for all the projects that should be checking their binary compatibility
• set mimaFailOnNoPrevious := false on specific projects that want to opt-out (alternatively disablePlugins(MimaPlugin))
• set mimaFailOnNoPrevious in ThisBuild := false, which disables it build-wide, effectively reverting back to the previous behaviour

#263 / #289

Dropped sbt 0.13 support

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.

#269 / #272

Dropped Scala 2.10 support

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.

#248 / #272

Improvements

Checking generic signatures

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.

#40 / #299

Additional improvements

• #162 / #254 Don't fail if an effectively final method becomes final
• #201 / #295 Don't fail when migrating from Java varargs to @varargs
• #168 / #323 Handle mimaPreviousArtifacts with dots in their name
• #239 Allow multiple filter files per version to be loaded from a directory
• #238 Improve the error message when filter files fail to be processed
• #305 Subsume the mima-reporter project (and jar) into mima-core

For full details see the 0.4.0 milestone and/or the 0.3.0...0.4.0 changelog.