Releases: lightbend-labs/mima
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
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
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
0.6.4
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.
0.6.2
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).
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 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).
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.
Additional improvements
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 (alternativelydisablePlugins(MimaPlugin)
) - 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.
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.
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.