-
Notifications
You must be signed in to change notification settings - Fork 21
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
[POC] Use Unroll plugin for binary compatibility #113
base: main
Are you sure you want to change the base?
Conversation
@@ -8,7 +8,7 @@ import com.github.lolgab.mill.mima._ | |||
|
|||
val scala212 = "2.12.17" | |||
val scala213 = "2.13.10" | |||
val scala3 = "3.1.3" | |||
val scala3 = "3.3.1" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is this intentional? We drop support for older Scala 3 version, which might be Ok, but should be done in a new 0.x
bump.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's a compiler plugin, so will need separate implementations for each Scala version I think.
It's possible to support 3.1.3, but the initial proof of concept is only against 3.3.1. Will have to decide whether or not to drop 3.1.3 before merging this, but I'd be in favor just to support the 3.3.x LTS versions
build.sc
Outdated
|
||
def ivyDeps = Agg( | ||
ivy"com.lihaoyi::unroll-annotation:0.1.9", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is unroll-annotation
needed transitively, or only at compile time?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Only at compile time. I can have the plugin remove the annotation if necessary, haven't thought deeply about whether that's the right thing to do
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We should move it into compileIvyDeps
then.
Since we are more or less generating stuff that is not part of the actual API but rather some inconvenient necessity, not forcing a transitive dependency on this implementation detail for all downstream users seem to be the right thing.
No description provided.