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

SIP-51: Drop forwards binary compatibility of the Scala 2 standard library #894

Open
SethTisue opened this issue Mar 4, 2025 · 0 comments

Comments

@SethTisue
Copy link
Member

SethTisue commented Mar 4, 2025

We are not quite ready to start merging standard library PRs that break forwards bincompat. Before merging anything, we'd like to understand the following better:

  • Does this interact/intersect with the work @hamzaremmal is doing on making a version of stdlib that's compiled by the Scala 3 compiler? How much of the motivation for SIP-51 will that eventually remove? Will it prevent Scala 2's TASTy Reader from working with some future Scala 3 version? Let's discuss at core meeting.

Some other concerns:

  • Mill isn't ready; there was a PR for Implement SIP-51 (unfreezing the Scala library) com-lihaoyi/mill#3075 but it stalled; however, at a recent SIP meeting @lihaoyi indicated willingness to get it moving again
  • Testing. @lrytz did some manual testing with Maven and Gradle, but we ought to have test scaffolds in version control somewhere so we can double check it for ourselves, to help convince others, and as a place we can quickly reproduce any issues that are reported
  • And what about Scala-CLI, is it ready?
  • Are there any implications for IntelliJ, do we need to be working with them in advance of 2.13.17 shipping?

We should probably start drafting the eventual blog post about this now, as the writing will aid our thinking. I have volunteered to write a first draft — it shouldn't be hard, since we can crib from the SIP itself.

The blog post should include:

  • Information about build tools (sbt, Mill, Maven, Gradle, Scala-CLI, IntelliJ, ...?)
  • Recommendations for library authors. We want to encourage them to adopt the Scala.js model where it's routine to take Scala 2 version upgrades even though it will require their users to upgrade as well.
    • Probably a library author wouldn't want to take the upgrade and then publish a new version on the same day a new Scala 2 version came out. What if that version turns out to have some significant regression? But then if not same day, what is a reasonable waiting period? Two weeks?
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

1 participant