publish for Scala 2.13.0-M4?

[SethTisue]

M4 JARs are on Maven Central now

in the 2.13 community build we are using https://github.com/SethTisue/scalacheck/tree/newCollections (forked from @lrytz who did most of the work)

[lrytz]

WIP at #411

[SethTisue]

Scala.js 0.6.23 is now published for M4

[rickynils]

#411 changes the API, due to the type changes (Stream -> LazyList, Traversable -> Iterable). I'm not sure how we should handle the releases and versioning from here on. It feels wrong to just release #411 as another 1.14.0 build. @SethTisue @lrytz Any thoughts on that?

[lrytz]

I think the we should "revert" the Stream -> LazyList change, and instaed add built-in generators for LazyList in the 2.13 version.

For the Traversable -> Iterable change, we can basically introduce a new type alias which, in 2.10/2.11/2.12 would be Traversable, and 2.13 would be Iterable.

Both of the above can be done with version-dependent source directories. This is a bit annoying to have, but I think it's better than having a separate branch for 2.13.

Let me know what you think, I'll put it in the PR.

[lrytz]

Once released, re-enable MiMa for 2.13.0-M4 in build.sbt (mimaPreviousArtifacts).

[ashawley]

I think the we should "revert" the Stream → LazyList change, and instead add built-in generators for LazyList in the 2.13 version.

Changing those as described would be necessary to publish 1.14.0 for 2.13.0-M4. Otherwise, it doesn't seem like the 1.14.0 release would be source compatible.

[lrytz]

That was done in the PR (#411) (which is still ready for review ☺️).

[ashawley]

The signature for Shrink was still using LazyList instead of Stream in the 2.13 build.

[ashawley]

Since Mima can't really check compatability with new versions of Scala, one other way to verify compatability is to try to export Scalacheck's test suite for 1.14.0 and try to compile it with this new 1.14.0 build (alongside the existing binaries). This assumes Scalacheck has sufficient test coverage of itself, but that may be a flawed assumption.

Regardless, I'd say it's worth publishing a 1.14.0 binary for 2.13.0-M4. If the 1.14.0 for 2.13.0-M4 doesn't work, then either fix what's broken by releasing a 1.14.1 for all versions of Scala, or if appropriate move everything to 1.15.0.

This is the procedure I did locally, and it checks out now that Shrink was just reverted in the PR:

1. Rebase the 2.13.0-M4 branch onto the old 1.14.0 tag so a 2.13.0-M4 binary can be built:

$ git fetch upstream master
$ git fetch -t upstream 1.14.0
$ git fetch lrytz m4
$ git checkout m4
$ git rebase --onto 1.14.0 upstream/master lrytz/m4

2. Publish just the Java M4 binary locally:

$ sbt ++2.13.0-M4 jvm/publishLocal

3. Then clone the 1.14.0 tag, and delete all the code except the test suite.

$ cd /tmp
$ git clone --branch 1.14.0 --depth 1 git@github.com:rickynils/scalacheck.git scalacheck-1.14.0
$ cd scalacheck-1.14.0
$ git rm -fr ./src/main
$ git rm -fr ./jvm/src/main

4. Overwrite the build as Java only by dropping the plugins, and add just a dependency for 1.14.0:

$ git rm -fr ./project 
$ git reset -- project/build.properties
$ git checkout -- project/build.properties
$ git rm build.sbt
$ cat << EOF > build.sbt
scalaVersion := "2.12.6"
crossScalaVersions := Seq("2.10.7", "2.11.12", "2.12.6", "2.13.0-M4")
libraryDependencies +=
  "org.scalacheck" %% "scalacheck" % "1.14.0"
EOF

5. Compile the test suite against 1.14.0 for all Scala versions:

$ sbt +update +test:compile

[lrytz]

Since Mima can't really check compatability with new versions of Scala

I'm not sure I understand what you mean here; When building with a new Scala version, there is nothing to compare against, and there doesn't need to be.

Binary compatibility needs to be checked only for new releases of scalacheck with an existing Scala binary version, e.g., 1.14.1 for 2.12 needs to be binary compatbitle with 1.14.0 for 2.12.

But 1.14.0 for 2.13 doesn't need to (and probably cannot) be binary compatible with 1.14.0 for 2.12.