Setup MiMa #18
Setup MiMa #18
Conversation
|
@cchantep I don't think we need to worry about compatibility with the milestone version. We probably will break binary compatibility anyway. Once 2.6.0 is released we can set up a maintenance branch for 2.6.x. |
|
2.6.0-M1 is the first release against which the MiMa check can be done. |
cchantep
force-pushed
the
feature/18
branch
2 times, most recently
from
af3d250
to
f5ba57a
Compare
| set -e | ||
|
|
||
| sbt clean scalariformFormat test:scalariformFormat | ||
| git diff --exit-code || ( |
There was a problem hiding this comment.
You can remove all these lines and use sbt validateCode instead. This way, most of this file would be unnecessary since it will only call sbt tasks. Instead, you can just remove it and add the following line to the .travis.yml script section:
- sbt ++$TRAVIS_SCALA_VERSION mimaReportBinaryIssuesSee #24 for more context.
| import com.typesafe.sbt.SbtScalariform._ | ||
| import scalariform.formatter.preferences._ | ||
|
|
||
| val previousVersion = "2.6.0-M1" // first from this separate repo |
There was a problem hiding this comment.
Maybe a better approach here is use something like play-slick. See https://github.com/playframework/play-slick/blob/6506de9228e17961cf121cee1b30044c9bf74920/build.sbt#L44-L52
Of course, after releasing a version and setting a branch for it, we should set the previousVersion variable to activate MiMa.
There was a problem hiding this comment.
I don't see the point there?
There was a problem hiding this comment.
@cchantep The point is so the code exists to enable MiMa, and when we create a new branch for the release we can activate it to test binary compatibility.
| resolvers ++= DefaultOptions.resolvers(snapshot = true) | ||
| resolvers += Resolver.typesafeRepo("releases") | ||
|
|
||
| addSbtPlugin("com.typesafe.play" % "interplay" % sys.props.get("interplay.version").getOrElse("1.3.4")) | ||
| //addSbtPlugin("com.typesafe.play" % "play-docs-sbt-plugin" % sys.props.getOrElse("play.version", "2.5.10")) | ||
|
|
||
| addSbtPlugin("com.typesafe" % "sbt-mima-plugin" % "0.1.8") |
There was a problem hiding this comment.
According to the docs, the most recent version of MiMa sbt plugin is 0.1.13.
cchantep
force-pushed
the
feature/18
branch
2 times, most recently
from
94f29cf
to
c5b9715
Compare
| @@ -14,6 +14,7 @@ before_cache: | |||
| - rm -rf $HOME/.ivy2/cache/com.typesafe.play/* | |||
| - rm -rf $HOME/.ivy2/cache/scala_*/sbt_*/com.typesafe.play/* | |||
| - find $HOME/.ivy2/cache -name "ivydata-*.properties" -print0 | xargs -n10 -0 rm | |||
| script: sbt ++$TRAVIS_SCALA_VERSION mimaReportBinaryIssues test | |||
There was a problem hiding this comment.
There is already a script section some lines above.
There was a problem hiding this comment.
My bad (rebase hell), updated
|
Should be ok now |
| import com.typesafe.sbt.SbtScalariform._ | ||
| import scalariform.formatter.preferences._ | ||
|
|
||
| val previousVersion = Some("2.6.0-M1") // first from this separate repo |
There was a problem hiding this comment.
As discussed, this should be set to None since we make no binary compatibility guarantees between milestone versions. Once we release 2.6.0, we'll set to Some("2.6.0"). We can also remove the filters below.
There was a problem hiding this comment.
I agree that's not a "normal" check: not thefirst version w/o a previous version, not a backward compatible release.
Even if this 2.6.0 will be a major version with some changes breaking the compat (such as the packages), I personnally prefer these breakage were "under control".
At least checking against M1, the API changes other than the packages renaming are validated (and other than what's ok to filter).
There was a problem hiding this comment.
@cchantep I do see your point; there is some value to knowing which APIs changed during a release. Why don't we try it, but change to 2.5.0? The artifact name is the same so it should be easy to do that. That way we'll actually know all the things that broke binary compatibility in the 2.6.0 release.
There was a problem hiding this comment.
That's what I wanted, but due to the package name change, it will detect everything inside as changed
There was a problem hiding this comment.
@cchantep Name changes could be handled by applying broader filters, for example, to filter out ValidationError issues, we can get pretty close by using { problem => !problem.ref.toString.contains("ValidationError") }.
If I understand correctly, the goal is to document the things that changed in this version, so it's much less useful if we use a milestone version.
Or we can just switch to None and not worry about it until we have a better solution. I don't think MiMa is well designed for this use case.
There was a problem hiding this comment.
The goal is to check that, except the package change for ValidationError, most of the API remains compatible.
The filter about ValidationError has been added. Checking against M1 is equivalent (more simple for me), as the changes between 2.5.12 and 2.6.0-M1 are only about this package change.
|
Updated |
No description provided.