-
Notifications
You must be signed in to change notification settings - Fork 5
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
Update deps, add Scala 3 support, drop Scala 2.12 #134
Conversation
Compared to conhub 1.2.1 the changes are source and binary compatible with these exceptions: - potential source compat breakage: NamedDispatcher doesn't have an implicit argument in the constructor anymore but it appears to be unused even in the internal Evolution codebase Changes highlights: - updated plugins and dependencies - added Scala 3.3.3 cross-compilation - removed Scala 2.12 support - introduced sbt-version-policy plugin and MiMa bincompat checks - fixed compilation warnings, minor test refactoring - replaced CurrentThreadExecutionContext usage with direct calls to ExecutionContext.parasitic since we do not support 2.12 anymore - Scala 3 compiler complained about NamedDispatcher implicit arguments in the constructor. Since the class is unused even in the internal Evolution codebase, implicit modifier was removed and the type was marked as deprecated.
Pull Request Test Coverage Report for Build 10723408465Details
💛 - Coveralls |
|
||
object Akka { | ||
private val version = "2.6.19" | ||
private val version = "2.6.21" |
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.
Not sure if we should bump Akka because it's patch versions are incompatible, so we can potentially get this error in downstream dependencies if they depend on Akka 2.6.19
java.lang.IllegalStateException: You are using version 2.6.21 of Akka, but it appears you (perhaps indirectly) also depend on older versions of related artifacts
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.
I believe everyone should be on 2.6.21 already, it doesn't seem to be a problem.
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.
and most of our OSS base akka support libraries are on 2.6.21 for months already
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.
No, we use .20 via overrides. The fact that our libraries are on .21 is a problem and not a reason for others to bump it too.
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.
I am afraid that it will sound arrogant, but prohibiting upgrades for all other projects because your one cannot or doesn't want to update is not a solution we can accept.
You are free to put overrides in your project or to not update some library at your own risk.
Please review changes in akka (https://github.com/akka/akka/releases/tag/v2.6.21) - they are very small and, most probably, will not have negative affect on your project.
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.
I stand with @mr-git here - Akka 2.6.21 is more than 1 year old now. If there is an internal reason for us to use older versions internally, there is no reason to have an outdated version in the opensource. Updating Akka 19 and 20 to 21 is trivial and by just trying to hold it in transitive dependencies is a loosing game. There are already dependencies which will bring 2.6.21 transitively (like safe-akka). If you want safeguards, they should be on the library client side - dependency overrides and such.
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.
@vilunov, am I right that we (including you) are using Akka 2.6.21
now? Shall we unblock the PR?
@migesok Overall it looks like you're making the assumption that Scala libraries adhere to SEMVER and if major version hasn't changed then it's safe to bump. Unfortunately this is often not the case with Scala libraries. I propose to keep MRs small. If you need Scala 3 I think it's better to only update what's needed for Scala 3 in this MR/ |
@migesok Unfortunately it is not possible since dependencies also have to have Scala 3 support and many of them didn't. |
overall LGTM but I'd like to wait for one more person to approve before merging |
|
||
object Akka { | ||
private val version = "2.6.19" | ||
private val version = "2.6.21" |
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.
No, we use .20 via overrides. The fact that our libraries are on .21 is a problem and not a reason for others to bump it too.
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.
I'll approve after we resolve the discussion about Akka version
@vilunov confirmed that the issue has been resolved |
Compared to conhub 1.2.1 the changes are source and binary compatible with these exceptions:
Changes highlights: