Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

publish for Scala 2.13.0-M4? #410

Closed
SethTisue opened this issue May 15, 2018 · 13 comments
Closed

publish for Scala 2.13.0-M4? #410

SethTisue opened this issue May 15, 2018 · 13 comments

Comments

@SethTisue
Copy link
Member

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
Copy link
Contributor

lrytz commented May 15, 2018

WIP at #411

@SethTisue
Copy link
Member Author

Scala.js 0.6.23 is now published for M4

@rickynils
Copy link
Contributor

#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
Copy link
Contributor

lrytz commented May 18, 2018

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
Copy link
Contributor

lrytz commented May 25, 2018

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

@ashawley
Copy link
Contributor

ashawley commented May 30, 2018

I think the we should "revert" the StreamLazyList 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
Copy link
Contributor

lrytz commented May 30, 2018

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

@ashawley
Copy link
Contributor

ashawley commented Jun 6, 2018

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

@ashawley
Copy link
Contributor

ashawley commented Jun 7, 2018

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
  1. Publish just the Java M4 binary locally:
$ sbt ++2.13.0-M4 jvm/publishLocal
  1. 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 [email protected]:rickynils/scalacheck.git scalacheck-1.14.0
$ cd scalacheck-1.14.0
$ git rm -fr ./src/main
$ git rm -fr ./jvm/src/main
  1. 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
  1. Compile the test suite against 1.14.0 for all Scala versions:
$ sbt +update +test:compile

@lrytz
Copy link
Contributor

lrytz commented Jun 7, 2018

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.

@ashawley
Copy link
Contributor

ashawley commented Jun 7, 2018

Indeed, there is no way for 2.13.0-M4 to be binary compatible. I was trying to verify that at least what ScalaCheck publishes as 1.14.0 for 2.13.0-M4 (everything in org.scalacheck) should at least be source compatible with 1.14.0. Since the PR for M4 has version-specific directories and collections library changes, that's more difficult to verify. Also, MiMa doesn't have a 2.13.0-M4 jar to compare with, so it can't help here, either. Locally publishing the PR for M4 and running the original 1.14.0 test suite is an alternative, albeit crude, way to verify compatability. It would have found the change with Shrink, for example.

@rickynils
Copy link
Contributor

I've now rebased and merged #411 to the 1.14.0_sonatype branch, and published JVM and JS builds of ScalaCheck 1.14.0 for Scala 2.13.0-M4.

Thanks for all your efforts @lrytz and @ashawley!

@lrytz
Copy link
Contributor

lrytz commented Jun 11, 2018

Yay, thanks @rickynils!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants