Binary compatibility

[raboof]

The README currently states:

We expect that new, binary incompatible releases of this library will be published (for 2.11, 2.12) until Scala 2.13 is getting close to its final state

When it is time to promise binary compatibility, we can

• replace that line with a statement around binary compatibility
• add MiMa checks to CI

[dwijnand]

May I suggest committing to binary compatibility in sync with the Scala 2.13.0-RC1 release? That would allow projects (like Akka) to easily cross-build and publish releases for Scala 2.13.

If you had to break binary compatibility (e.g for RC2) you could just come up with another artifactId and package name... It would be a little unfortunate, but still reasonably recoverable (just need some naming creativity 😄).

[SethTisue]

(despite the no-bincompat-yet warning in the readme, it still probably would have been better if I'd called the new release 0.3.0 instead of 0.2.2)

[dwijnand]

Btw, both Akka and Play have avoided this pitfall by copying subsets of scala-collection-compat into the project.

[dwijnand]

May I suggest committing to binary compatibility in sync with the Scala 2.13.0-RC1 release? That would allow projects (like Akka) to easily cross-build and publish releases for Scala 2.13.

Welcome, Scala 2.13.0-RC1! Any thoughts on this idea, @szeiger?

[raboof]

(FWIW, for Akka we've decided to avoid depending on the scala-collection-compat library, but are taking it as a reference while including only those compatibility measures that are required for our codebase)

[szeiger]

I'm currently looking through the library code and the open tickets to ensure we're in a state where we can enforce binary compatibility.

[szeiger]

We published version 1.0.0. The only remaining task is to enable MiMa.

[szeiger]

It may already be time to switch to a new artifact name because we'll have to break binary compatibility for #195

[raboof]

Or perhaps 2.0.0? Given that 2.13.0 is not yet GA I don't think switching to a new artifact name is necessary yet.

[szeiger]

Yes, that might be OK during the release cycle. Since we cannot rely on a module system we'd also have to rename the package (thus breaking source compatibility) if we rename the artifact.

[eed3si9n]

+1 for 2.0.0.

[xuwei-k]

not binary compatible due to #220 😢

"org.scala-lang.modules" % "scala-collection-compat_2.11" % "2.0.0"
↓
"org.scala-lang.modules" % "scala-collection-compat_2.11" % "2.1.1"

 * method toMapViewExtensionMethods(scala.collection.IterableView)scala.collection.IterableView in trait scala.collection.compat.PackageShared is present only in current version
   filter with: ProblemFilters.exclude[ReversedMissingMethodProblem]("scala.collection.compat.PackageShared.toMapViewExtensionMethods")

[NthPortal]

are we committing to forward and backward bincompat, or just backward?

[xuwei-k]

I think #220 break backward bincompat, not only forward

[dwijnand]

It seems fine to me.

ReversedMissingMethodProblem means introducing this method could break existing extensions of this class/trait, so backwards binary incompatibility. (Also forward incompatibility, for completeness.).

But PackageShared is private[compat] so it has no public children that could be broken.

(Also in 2.12 it should implement with default methods so not binary backwards incompatible either, but we also target 2.11 here.)

I think we can close this issue once we've set up MiMa.

[szeiger]

As Dale said, the trait is package-private (which MiMa doesn't see) and should not be extended by users. And like any other Scala library we only care about backwards compatibility. Only the standard library is different because of the distribution mechanism.

[SethTisue]

according to @julienrf at #288, @xuwei-k was right to begin with

we're facing this again at #367