v0.8.1 ChangesOctober 19, 2020
- 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
- ⚡️ 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
v0.8.0 ChangesSeptember 08, 2020
🆕 New features
- 👉 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
v0.7.0 ChangesFebruary 28, 2020
- Checking generic signatures is now opt-in. #471
Most MiMa checks (
IncompatibleMethType, etc) are against the method
descriptor, which is the "raw" type signature, without any information about generic parameters.
IncompatibleSignaturecheck 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.
0️⃣ This check is now disabled by default. You can opt-in to it by setting:
ThisBuild / mimaReportSignatureProblems := true
- 👌 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
- 🛠 Fix a regression in how version filtered are... filtered. #468
- ⬇️ Drop Bintray, switch releasing the plugin to Maven Central. #469
v0.6.3 ChangesFebruary 03, 2020
- 🛠 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)
- 📄 Clarify the
IncompatibleSignatureProblemmessage & 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.
v0.6.2 ChangesFebruary 03, 2020
🚀 (Failed release. Details in the release tracking issue: #454)
v0.6.1 ChangesSeptember 20, 2019
💥 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.
🚀 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).
v0.6.0 ChangesAugust 22, 2019
- 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
⚡️ The last 2 highlighted changes fix the fact that previously some
DirectMissingMethodProblems were incorrectly reported as
IncompatibleMethTypeProblemand 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
DirectMissingMethodProbleminstead (example: https://github.com/akka/akka-http/pull/2656/files).
v0.5.0 ChangesJuly 12, 2019
🛠 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
mimaReportBinaryIssuesbut hadn't configured
⚡️ 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
mimaPreviousArtifactswas 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
mimaReportBinaryIssuesnot fail sections, the latter of which details how use 0.4.0's
mimaFailOnNoPrevioussetting to handle breakages.
➕ Additional improvements
v0.4.0 ChangesJuly 09, 2019
💥 Breaking changes
0️⃣ When mimaPreviousArtifacts is not set, default mimaReportBinaryIssues to fail
0️⃣ As of v0.4.0
mimaReportBinaryIssueswill, by default, fail if
mimaPreviousArtifactsis 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:
mimaPreviousArtifactsfor all the projects that should be checking their binary compatibility
- 🔌 set
mimaFailOnNoPrevious := falseon specific projects that want to opt-out (alternatively
- 🏗 set
mimaFailOnNoPrevious in ThisBuild := false, which disables it build-wide, effectively reverting back to the previous behaviour
⬇️ 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.
⬇️ 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.
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
⬆️ This change also fixes a problem where
IncompatibleResultTypeProbleminstances were missed. This means that this upgrade may require adding filters for old, but previously undetected, incompatibilities.
➕ 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
- #168 / #323 Handle
mimaPreviousArtifactswith 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.