search

lightbend-labs / mima

A tool for catching binary incompatibility in Scala
Apache License 2.0
459 stars 71 forks source link

Possibility to set check direction per artifact #615

Open nafg opened 3 years ago

nafg commented 3 years ago

AFAICT there is currently no way to set the check direction to "both" for previous artifacts that differ in patch version, and to "backward" for previous artifacts that differ in minor version.

Is this possible (without sbt set ... on the command line or custom sbt commands), and if not should it be?

dwijnand commented 3 years ago

Is this possible (without sbt set ... on the command line or custom sbt commands), and if not should it be?

I don't think it is, and "should it be" is so philosophical. 😄 What's the real world use-case here? The current standard is backwards, because once you declare you're using libfoo v1.2.3, transitive dependency management means that users that compiled against v1.2.3 aren't going to run against v1.2.0 instead. The only exception to the rule is scala-library (and "experimental" scala-reflect) and that's only true because it's special-cased in sbt, and it's there for legacy reasons. So I don't see why this would be needed.

nafg commented 3 years ago

I think I misremembered something but in any case https://docs.scala-lang.org/overviews/core/binary-compatibility-for-library-authors.html suggests checking both directions as an approximation for source compat. So the idea would be to check with direction set to both for patch bumps and backward for minor bumps.

On Tue, Apr 20, 2021, 3:05 AM Dale Wijnand @.***> wrote:

Is this possible (without sbt set ... on the command line or custom sbt commands), and if not should it be?

I don't think it is, and "should it be" is so philosophical. 😄 What's the real world use-case here? The current standard is backwards, because once you declare you're using libfoo v1.2.3, transitive dependency management means that users that compiled against v1.2.3 aren't going to run against v1.2.0 instead. The only exception to the rule is scala-library (and "experimental" scala-reflect) and that's only true because it's special-cased in sbt, and it's there for legacy reasons. So I don't see why this would be needed.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/lightbend/mima/issues/615#issuecomment-823029665, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAAYAUEEHZUQ2CH26ZCG7U3TJURU3ANCNFSM43ET7HEQ .

SethTisue commented 3 years ago

checking both directions as an approximation for source compat

@dwijnand see discussion at https://github.com/scalacenter/sbt-version-policy/issues/71 — you'll see there that this business of using a bidirectional bincompat check as a proxy for source compatibility was new and surprising to me as well

(apparently that passage in https://docs.scala-lang.org/overviews/core/binary-compatibility-for-library-authors.html didn't stick in my head, though I must have read it at some point)

dwijnand commented 3 years ago

I agree with @eed3si9n's point, which I don't think I can see being addressed in that thread:

In that sense, checking for source compatibility is not difficult. You write unit tests all API points that you care about. If you have to change your existing unit tests either in the code invocation or the expected value, you've likely broken the source compatibility.

and about how restrictive forwards compatibility can be, for that 0.01% chance of a source incompatibility.