Join GitHub today
"sbt '++ 2.13.0-M2!' compile" does not work with sbt 1.0.0 #453
To verify that the new bridge compiles, it needs to compile using sbt 1.0.3, which is unable to compile 2.13 code until this fix goes in. To work around this chicken-egg, I've manually created a bridge and published it to Maven Central as
I kept the original commit from #445, but it didn't compile when I hooked it up with my bridge.
This also splits up the tests into a separate subproject since the test requires more dependencies than the actual bridge, which only relies on compiler|util-interface.
It generally looks good. I've added several comments and I've only looked through the build changes because the PR has to be rebased on the open PRs that change the build and have been ready for review in a while: #428, #429. I'll have a closer look when they are.
Also, can you give a high-level explanation of these changes and why you make them? I don't understand some of the design decisions taken here. The PR message doesn't contain a descriptive explanation.
Otherwise, good job!
I would personally prefer if we had stable names for the source directories, and avoided using names such as
scala_2.13+. When work on 2.14 starts, we'll likely need to rename that directory to
scala_2.13, which will make browsing the history harder for no good reason.
In retrospect, and given the recent tickets in https://github.com/scala/scala-dev/milestone/18 and the fact that 2.14 will be a compiler-focussed release, I agree with you - it's fairly likely we'd need to tweak our compiler bridge for 2.14. Good shout.
If a bug fix patch against 1.0.x is ready to go, I don't think pending PRs should block it. This particular bug fix has been going on for a really long time, and it's not a super high priority one, but as a general matter, we should be able to patch bugs at relatively short turnaround. That's the point of having 1.0.x branch.
As per the build improvement PRs, I haven't paid too much attention to them since there's been review activities already, but if there are unresolved issues, let's discuss in weekly meeting.
... Eugene, I disagree and I've commented on the PR why #428. There has been a lot of work into those PRs, and the fact that they haven't been reviewed in a long time and this PR now wants to override it is not nice.
As I say in the other thread, that policy has been created by you and at any point has been discussed with me. On top of it, it's not consistent with the past -- we've merged not only bug fixes into 1.0.x.