Wow! Thanks for the investigation. What's your sense of the magnitude of this change? How did you adapt your forks to the new syntax?

@adriaanm In the forks, I've been replacing symbol literals with the sym"id" short-hand syntax from scala/scala#7495. I had to backport it to 2.12 in scala/scala#7585 so I can test in the 2.12 community build.

I've had a few passes here with running dbuild locally, and it already affects close to 20 projects. Hoping to run it on Jenkins to confirm that and see if there are any more that surface.

I'd say that there aren't a lot of community projects using symbol literals, but the ones that are affected are Scala tools like test frameworks, so projects that in turn use those test frameworks are similarly impacted. This has the butterfly effect where deprecating and dropping symbol literals needs to ripple through the community projects. This is probably a common scenario for these types of changes to Scala that cascade like this.

I merged origin/2.12.x onto your branch and triggered https://scala-ci.typesafe.com/view/scala-2.12.x/job/scala-2.12.x-integrate-community-build/3937/ (404 til Jenkins rouses himself from his slumber)

Thanks, Seth. How do I configure it to use the compiler artifacts from scala/scala#7585? I had been accomplishing it locally with ./run.sh -v 2.12.8-bin-87ed2be-SNAPSHOT, but I couldn't figure out what Jenkins is expecting.

oh sorry, I should have been paying closer attention. triggered a new job with the Scala version specified:
https://scala-ci.typesafe.com/view/scala-2.12.x/job/scala-2.12.x-integrate-community-build/3942/ (404 til Jenkins wakes up)

oh, ha, 2.12.9-bin-, not 2.12.8-bin-. https://scala-ci.typesafe.com/view/scala-2.12.x/job/scala-2.12.x-integrate-community-build/3945/

Thanks, Seth. Could I have one more run? I tried forking akka, spray-json and lift-json.

I'd suggest that you merge 2.12.x onto your branch before we do the next run.

Ok, done.

A lot of the things that you had to fix on the 2.12.x branch I already had pinned to forks I froze last month. It also added some knew projects, so we'll see what happens.

Seth,

A lot of my forks are frozen from early December, so there's a good chance that that will cause problems. I didn't think that it would be a problem for the 2.12 community build, but I'm seeing otherwise and you probably know very well it to be the case. Bit rot is real.

I don't think I'll have the time to do another full iteration of this. I was able to get pretty far. You probably have more pressing 2.13 priorities. With respect to learning more about dropping symbols, it seems like diminishing returns, anyway.

okay, makes sense.

a piece of advice I should have thought to offer earlier: this repo has a freeze script at the root level that lets you freeze all the project SHAs at whatever some Jenkins run that you pick used. And it's also possible to just rewind to the last time we froze for a release and work from that. Either way, it stops everything from constantly changing out from under you.

@ashawley did this experiment produce any conclusions that you should record at scala/scala#7395 ? (which I'm still inclined to go forward with)

This has the butterfly effect where deprecating and dropping symbol literals needs to ripple through the community projects

fwiw, I'm comfortable with that. deprecate-in-2.13, drop-in-2.14 is a multi-year timetable. and by deprecating first, we don't break the community build and we don't prevent projects from publishing.

Yes, that would be the ideal timetable. It's difficult though. When it is dropped in 2.14, those libraries that expose symbol literals will need to handle cross-compiling for both situations if they, and most likely they will, need to cross-publish for 2.12, 2.13 and 2.14.