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

add scala 3 release version flag #241

Closed
wants to merge 7 commits into from
Closed

add scala 3 release version flag #241

wants to merge 7 commits into from

Conversation

i10416
Copy link

@i10416 i10416 commented Apr 4, 2022

No description provided.

@i10416
Copy link
Author

i10416 commented Apr 4, 2022

rel #138

@armanbilge
Copy link
Member

armanbilge commented Apr 4, 2022

Thanks for the PR! :) A few quick notes:

  • Actually the compiler flag was renamed to -scala-output-version :)
  • Unfortunately, adding the compiler flag is not sufficient; we also need to modify the POM to use the old Scala standard library instead of the new one. Fortunately, sbt 1.7.0 will implement the extra functionality, so we can directly integrate with their setting.
    https://github.com/sbt/sbt/releases/tag/v1.7.0-M1
  • I think we should make the default Scala 3.1.1

Also, would you mind targeting your PR at main branch instead of series/0.4? We will release this feature in sbt-typelevel v0.5.0 :)

@armanbilge armanbilge linked an issue Apr 4, 2022 that may be closed by this pull request
@i10416 i10416 changed the base branch from series/0.4 to main April 4, 2022 23:29
@i10416
Copy link
Author

i10416 commented Apr 4, 2022

Hmm, should we wrap scalaOutputVersion := "3.0.2" in tlScalaRelease rather than exposing it to users?

@armanbilge
Copy link
Member

That's a good question. I don't think we need our own tlScalaRelease setting. I'm not sure what we would use it for.

@i10416
Copy link
Author

i10416 commented Apr 4, 2022

Sure.

In addition, are we going to use scalaOutputVersion here, which is still pre-release , or wait for next sbt release?. What do you think?

@armanbilge
Copy link
Member

armanbilge commented Apr 4, 2022

I think it's too hard to support this Scala 3 feature without relying on the sbt integration. So, we definitely need to rely on that scalaOutputVersion setting.

I can't promise I'll merge this PR right away. I have to double-check when the planned release date for sbt v1.7.0 is and and decide whether sbt-typelevel v0.5.0 should wait for it or not. I don't currently feel a big rush to release sbt-typelevel v0.5.0 so that strategy may make sense.

Meanwhile I am publishing some milestone prereleases of sbt-typelevel v0.5.0 so some people can use that with the sbt milestone prerelease, if they want.

@i10416
Copy link
Author

i10416 commented Apr 5, 2022

Okay. I'm not in a hurry too.
We'd better waiting for sbt 1.7.0 release for v0.5.0. I close this PR for now so that someone desperately needs that feature can feel free to open PR.

@i10416 i10416 closed this Apr 5, 2022
@i10416
Copy link
Author

i10416 commented Apr 5, 2022

@armanbilge Thanks for reviewing :)

@armanbilge
Copy link
Member

Thanks for your contribution! :)

@armanbilge
Copy link
Member

@i10416 if you're still interested in working on this one, I had an idea for how we can do this so it will be ready before sbt 1.7.0 is released, and also so we don't have to bump to sbt-typelevel 0.5.0.

Basically, the idea is to use sbt "reflection", when you refer to a setting using a String. Here's an example:

ThisBuild / SettingKey[Option[ModuleID]]("tlSiteApiModule") := Some(projectID.value)

This technique will work even if somebody uses sbt-typelevel with sbt 1.6.x. It won't do anything, but at least it won't crash the build :)

@i10416
Copy link
Author

i10416 commented Apr 29, 2022

@armanbilge Oh! I didn't know that technique.

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

Successfully merging this pull request may close these issues.

None yet

4 participants