track scalacheck

[adriaanm]

Currently at "rickynils/scalacheck.git#1.11.1", but master should be fine

[SethTisue]

moving to 1.12 is tricky because there are source-incompatible changes. gory details in the wip commits at #119

[SethTisue]

we should look at this again after 2.12.0 is done and we remove the Scalacheck sources from the scala/scala repo

[SethTisue]

it's no longer relevant that the scala/scala repo includes the ScalaCheck sources, because the community build doesn't build Scala anymore, and there is no ScalaCheck in the published Scala jars. so we're free to try again.

there's a good chance it might actually be easy(-ish?) now to move at least to 1.12.x, maybe 1.13.x

[SethTisue]

this looks very very promising:

I have a WIP branch SethTisue/community-builds#scalacheck-upgrade just going to 1.12.x. a test run very nearly succeeded: https://scala-ci.typesafe.com/view/scala-2.12.x/job/scala-2.12.x-integrate-community-build/737/consoleFull

only scala-partest failed to build:

[scala-partest] [error] /home/jenkins/workspace/scala-2.12.x-integrate-community-build/target-0.9.5/project-builds/scala-partest-7721fdf5ade65e4fc588bc0ad5df26ec3d9de596/src/main/scala/scala/tools/partest/nest/Runner.scala:586: type mismatch;
[scala-partest] [error]  found   : org.scalacheck.ScalaCheckFramework
[scala-partest] [error]  required: org.scalatools.testing.Framework
[scala-partest] [error]       val f: Framework = new org.scalacheck.ScalaCheckFramework
[scala-partest] [error]                          ^

scala-partest's current ScalaCheck dependency is 1.11.x, so this is probably some trivial 1.11.x vs 1.2.x we could resolve on a branch, and then that branch would get merged onto scala-partest master after 2.12.0 is done

[SethTisue]

yay we're on 1.12.x now.

as for going to 1.13.x, several projects are still on 1.12.x and there are compilation errors because of source-incompatible changes to ScalaCheck

• scalaz 7.2.x (7.3.x is on 1.13.x, but the change wasn't backported to 7.2.x)
• spire

three possible solution approaches:

• use spaces to support both 1.12 and 1.13
• stick with 1.12 for now and disable tests on any project requiring 1.13
• move to 1.13 and disable tests on any project requiring 1.12

I think I lean towards the third option? we kind of expect included projects to keep their dependencies generally current, and ScalaCheck 1.13 has been out since February 2016.

[SethTisue]

one other option would be to compile ScalaCheck 1.13 in its own space (SethTisue@dbfe1d4) but not actually use it anywhere. I'm not sure that really adds enough value to be worth doing — it's not all that likely that there would be some code in 1.13 only that would tickle some Scala bug.

let's just stay on 1.12 for now. parking this ticket.

fyi @rickynils @non @xuwei-k

[non]

I'll try to upgrade Spire ASAP.

[xuwei-k]

now spire depends on scalacheck 1.13

typelevel/spire@4268d92f#diff-fdc3abdfd754eeb24090dbd90aeec2ceR7

scalaz 7.2.x (7.3.x is on 1.13.x, but the change wasn't backported to 7.2.x)

scalaz/scalaz#1282 backported

[SethTisue]

scalaz/scalaz#1282 backported

@xuwei-k nice! seriously, that's really helpful.

and, great news about Spire.

I won't have time to return to this ticket until January or maybe February, but it's still very much on my mind. it's the most important pending change to our projects list.

[SethTisue]

lift-json is the latest project to now require 1.13

[SethTisue]

tried adding http4s, but it needs cats-laws, which needs 1.13