-
Notifications
You must be signed in to change notification settings - Fork 59
2.13: move to new collections #710
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
Comments
trying to get down to a minimal core of green projects plus projects that are very high priority to get green references #710
after 1338c90, in local testing,
|
for scalacheck there's a pr / branch. on my phone right now |
@lrytz thanks, using that now. and I fixed kind-projector. nscala-time and sbinary are now giving:
which puzzles me. perhaps |
Oh I forgot to mention: if you build scalacheck from my branch (https://github.com/lrytz/scalacheck/tree/newCollections), the groupId changed to org.scala-lang.modules (lrytz/scalacheck@2013eca). So you'd have to revert that. |
ahhhhhhhhh :-) |
fixed scalaprops scalaprops/scalaprops@b98d71c |
For the record, to not duplicate work: I'm working on scala-java8-compat (almost done), i have a local path for genjavadoc, and @ennru created a branch for akka-actor (https://github.com/ennru/akka/tree/newCollections). |
@SethTisue kind-projector compiles without warning and the tests pass with scala-2.13.0-pre-1c0be29. Can you point me to the error you faced? |
I'll take macro-paradise |
@adriaanm ping me when you're done with that and I'll get shapeless into shape. |
status report:
we would like to get M4 out in time for Scala Days Berlin (May 14) |
macro-paradise progress can be followed at scala/scala#6606 |
these are the currently failing projects. as in all their upstream dependencies are green, but the project itself fails:
volunteers wanted, to tackle particular projects. or at least to investigate and report back on the nature of the failure and the expected difficulty of fixing it https://scala-ci.typesafe.com/job/scala-2.13.x-integrate-community-build/1091/consoleFull has the failure logs. |
- scala/community-build#710 - https://scala-ci.typesafe.com/job/scala-2.13.x-integrate-community-build/1092/consoleFull ``` [sbt-io] [error] /home/jenkins/workspace/scala-2.13.x-integrate-community-build/target-0.9.12/project-builds/sbt-io-1aeb11a3d751ba13cb0d1d22d082306f3c24a209/io/src/main/scala/sbt/io/MacOSXWatchService.scala:61:32: overloaded method value flatMap with alternatives: [sbt-io] [error] [K2, V2](f: ((java.nio.file.Path, sbt.io.MacOSXWatchKey)) => scala.collection.IterableOnce[(K2, V2)])scala.collection.mutable.Map[K2,V2] <and> [sbt-io] [error] [B](f: ((java.nio.file.Path, sbt.io.MacOSXWatchKey)) => scala.collection.IterableOnce[B])scala.collection.mutable.Iterable[B] [sbt-io] [error] cannot be applied to (((java.nio.file.Path, sbt.io.MacOSXWatchKey)) => Option[(sbt.io.MacOSXWatchKey, scala.collection.mutable.Buffer[java.nio.file.WatchEvent[java.nio.file.Path]])]) [sbt-io] [error] .synchronized(registered.flatMap { [sbt-io] [error] ^ [sbt-io] [error] /home/jenkins/workspace/scala-2.13.x-integrate-community-build/target-0.9.12/project-builds/sbt-io-1aeb11a3d751ba13cb0d1d22d082306f3c24a209/io/src/main/scala/sbt/io/MacOSXWatchService.scala:61:32: overloaded method value flatMap with alternatives: [sbt-io] [error] [K2, V2](f: ((java.nio.file.Path, sbt.io.MacOSXWatchKey)) => scala.collection.IterableOnce[(K2, V2)])scala.collection.mutable.Map[K2,V2] <and> [sbt-io] [error] [B](f: ((java.nio.file.Path, sbt.io.MacOSXWatchKey)) => scala.collection.IterableOnce[B])scala.collection.mutable.Iterable[B] [sbt-io] [error] cannot be applied to (((java.nio.file.Path, sbt.io.MacOSXWatchKey)) => Option[(sbt.io.MacOSXWatchKey, scala.collection.mutable.Buffer[java.nio.file.WatchEvent[java.nio.file.Path]])]) [sbt-io] [error] .synchronized(registered.flatMap { [sbt-io] [error] ^ [sbt-io] [warn] one warning found [sbt-io] [error] one error found [sbt-io] [info] No documentation generated with unsuccessful compiler run [sbt-io] [warn] two warnings found [sbt-io] [error] one error found [sbt-io] [error] (io / Compile / compileIncremental) Compilation failed [sbt-io] [error] (io / Compile / doc) Scaladoc generation failed ```
@xuwei-k there is now a further error in sbinary:
|
Should we create a wiki page, in either this repo or scala/scala, to track this? (ala https://github.com/sbt/sbt/wiki/sbt-1.x-plugin-migration / https://github.com/sbt/sbt/wiki/library-sbt-1.x-migration) |
currently (here's a recent run) 41 projects are green the highest priority failures (the ones blocking the most projects downstream are):
the full failures list (not including projects blocked by failing dependencies) currently is: magnolia, scala-js, scala-refactoring, scala-async, minitest, shapeless, scala-continuations, utest, scala-collections-laws, linter, spray-json, twirl, scallop, sksamuel-exts, scalamock, paradox, mima, scalajson, grizzled, slick, scoverage, jackson-module-scala, scala-stm, parboiled, akka-actor, scapegoat, pcplod, scalikejdbc, lift-json, cachecontrol, scalastyle, scalaz8, log4s, http4s-parboiled2, scalatest-tests, scala-swing, cats, tut misc notes:
|
For Scala.js, while waiting for the parallel collections, you could try pruning this line to only keep |
@SethTisue scala/scala PR addressing the shapeless failure here: scala/scala#6971. |
Create new wiki page for 2.13.0-M5? or reuse https://github.com/scala/community-builds/wiki/scala-2.13.x-migration? |
I'd say let's keep that URL from M5, and move the M4 content to another page. |
utest should be back on track com-lihaoyi/utest#180 |
Haven't posted an update here in a while, since I have been concentrating instead on encouraging library authors to publish for 2.13.0-M5, since usually that results in the project going green in the community build as well. but anyway, the current status in a recent run such as https://scala-ci.typesafe.com/job/scala-2.13.x-integrate-community-build/1529/ is:
once cats is published for M5, it should go green here as well. scala-java8-compat is on my plate, but it would be awesome if someone volunteered to tackle it. ssl-config can wait until #808 is merged. almost everything else on the list is probably fair game if anyone wants to try to help the maintainers move to 2.13. |
(note that the logs on Jenkins now end with these stats and the sorted list, I added that in August, 1b5e0e6) |
a sample recent run is https://scala-ci.typesafe.com/job/scala-2.13.x-integrate-community-build/1593/console the big news is that cats is now green... except it's missing cats-kernel-laws, which several downstream projects need (algebra, circe, kittens, paiges) the current top-blockers list is:
the numbers are how many downstream projects are blocked |
at https://scala-ci.typesafe.com/job/scala-2.13.x-integrate-community-build/1630/ we're up to 78 green projects
|
looks like fastparse ran afoul of scala/scala#6218, @som-snytt does this look as expected? |
…t` that failed last run of the community-builds: scala/community-build#710 (comment)
no (#611) the easiest thing is to use dbuild with a reduced config file so it doesn't extract dependencies from 180 projects you don't care about. I made this branch of the community build that has only fastparse and its dependencies: https://github.com/SethTisue/community-builds/tree/fastparse-only . just grab the branch and |
Perhaps a nice feature will be to able to specify the required library as an (optional) argument and the community build script will only build that specific library and its dependencies. |
note that it does something like that already, in the sense that so, yes: it would be nice if there was a way to say "don't even extract any projects I didn't mention on the command line". but deleting the entries you don't care about from the config file is generally not that hard, so it's not absolutely clear it would be worth Toni's time to automate it more, given that dbuild only has a few users |
Is it possible to somehow query scaladex to achieve this easier? |
@soronpo scaladex only has runtime dependencies. in this context we need compile-time dependencies, including test-only dependencies. |
I've deleted the best way for anyone to check the current status is to look at the log of a recent run at https://scala-ci.typesafe.com/job/scala-2.13.x-integrate-community-build/ and the expected-to-fail project list at https://github.com/scala/community-builds/blob/2.13.x/report/Report.scala (which I do actively maintain) |
overall the current status is: we've been hovering at around 80 green projects. I've been tackling any significant regressions myself, enlisting project maintainers' help as needed it's now been so long since M5, and so many little breaking changes have accumulated, that it's not really productive at present to do any better than ~80 after 2.13.0-RC1 is out, we can make a fresh attempt to get more projects green.
(meanwhile, I have continued this nagging campaign) |
I think https://github.com/scala/community-builds/wiki/scala-2.13.x-migration served the initial purpose of bootstrapping the ecosystem for the new breaking pre-release of 2.13. When 2.13.0-RC1 comes out it'll be useful to swarm over those usual suspect libraries that'll need updating. And when 2.13.0 is out we'll port even more than usual. |
potential 2.13.0-RC1 release blockers in the community build are being tracked at scala/bug#11453 until RC1 is out |
RC1 is out. I'm going to close this ticket, since:
|
RC2 is out 122 projects are green now (up from 94 six weeks ago) there aren't currently isn't anything readily actionable blocking many downstream projects. scalameta (blocking 12) is difficult, see #910 jawn 0.10 (blocking 9) isn't worth upgrading, we only need it for building sbt and its modules. we can wait for sbt itself to move to 2.13 and the other blocker numbers are small. I'll chip away it in the coming months. (community help with this is welcome) |
162 green projects these days (2.12 has 204) |
774c22c flips the switch. now to deal with the failures
The text was updated successfully, but these errors were encountered: