[1.3.0] sbt plugin does not work with 1.2.8 if plugin build with 1.3.0 #5049
Comments
|
workaround --- a/src/main/scala/example/ExamplePlugin.scala
+++ b/src/main/scala/example/ExamplePlugin.scala
@@ -4,6 +4,6 @@ import sbt._, Keys._
object ExamplePlugin extends AutoPlugin {
object autoImport {
- val foo = settingKey[File]("")
+ val foo = SettingKey[File]("foo")(implicitly, sbt.util.NoJsonWriter())
}
} |
|
@xuwei-k Thanks for the report! Maybe it's ok for sbt to be backward compatible only? |
|
While the problem is unfortunate and super-subtle (nice detective work!) I think requiring sbt to be forward-compatible is too much to ask. The way we allow that not to be a problem is by making each sbt update reasonably easy (in comparison to scala major updates, which require all your dependencies to be rebuilt). |
|
On the other side, you can safeguard your plugin from these problems by specifically testing for target sbt versions, so |
|
Another way to guard against this is to pin the sbt version in your build, e.g. |
|
I wonder if it might make sense to add a way of configuring the sbt compatibility level of |
That's a nice workaround. Maybe in general we should rethink the idea of always using the sbt version used for the build as the plugin's dependency, and we should default to some old version from 1.1.x or |
|
I'm stating the obvious, but it might be a useful comparison: this would be like building an extension to akka-actor 2.5.23 and then someone complaining it doesn't work with akka-actor 2.5.15. I think it's fine, but we could/should bring this to light, for existing plugin authors, and for future ones by adding to the plugin or scripted docs. |
|
I agree with that. The important distinction though is that the api is opaque about what version of sbt you’re targeting. I can empathize with what happened with the sonatype plugin because I easily would have made the same kind of mistake. I think better documentation would go a long way. |
I guess I am considering that we decouple two sbt's:
Plugin authors are often the most advanced sbt users, so it would be unfortunate to tell them to stay in the oldest sbt 1.x possible to maximize their plugin's compatibility. |
|
You can already do that with The notion of "minimum version" I think applies to situations where users are for some reason stuck on older versions. I think that doesn't (or shouldn't) apply to sbt as it should strive to always be reasonably easy to upgrade. |
|
I suggest we recommend the following setting: pluginCrossBuild / sbtVersion := "1.2.8"ConfirmationI also tested it by loading it to a build using sbt 1.2.8. Given there many plugins are falling into this pitfall, I think we should address this by default. For example we can set it to some older version by default (1.2.8, for now?) starting sbt 1.4.0, and we can let plugin authors to opt into depending on newly released sbt. |
Force sbt version in plugin to 1.2.8, workaround for sbt/sbt#5049
|
Is there any plan to fix this in v1.4 ? |
|
@kiranbayram I have not taken any action on this. Do people have opinion on how this should be addressed? Do we use |
|
I think folks who feel they need to stick with 1.2.x, for whatever reason, ought to be okay also sticking with already-published plugin versions. I believe it is more important to keep sbt and its plugin ecosystem moving forward. If there are still critical issues with 1.3.x that prevent people from upgrading, I think it's better to put the effort into finding fixes and/or workarounds for those issues, rather than catering to users of outdated versions. |
|
It's a classic Crossing the Chasm curve situation. Whenever a new 1.y feature release of sbt comes out, the adoption rate goes through a bell curve. The open source library authors and plugin maintainers likely would be in the natural earlier adopter. Eventually in a few months or so, early majority and even late majority would adopt the new feature release, in this case 1.3.x. But the plugin authors may or may not want their audience to adopt 1.3.x immediately given that it might require some additional work, such as validating Coursier. Now 1.3.13 feels relatively stable, but when it came out it was pretty edgy. Now, to up the ante, consider sbt 1.4.0. When I publish a new version of sbt-assembly or sbt-buildinfo, should the build users forced to immediately adopt sbt 1.4.0 (and potentially run into early issues)? Unlike Scala standard library, sbt doesn't maintain forward compatibility so I think plugins compiling against an older sbt is a valid choice. The part I am not totally sure is what that version should be, and how it's determined. |
|
Here's a PR to hard code to 1.2.8 - #5918 |
|
It'd be useful if plugin's author could have a hook that is called before any of the plugins' is actually loaded by sbt (the goal would be to validate plugins' compatibility before loading the project). In the meanwhile, here is what I'm doing to help users solve their issue: If there is a better way, please point it out :) EDIT: I should have mentioned that I tried the original workaround suggested by @xuwei-k, but unfortunately it didn't quite work in my case (I got back an error about settings not being named properly, but I didn't investigate much further). |
|
In which file, do I add this line?
|
|
In |
workaround by eed3si9n
original report by xuwei-k
steps
sbt version: 1.3.0
build.sbt
project/build.properties
src/main/scala/example/ExamplePlugin.scala
src/sbt-test/a/b/build.sbt
src/sbt-test/a/b/project/build.properties
src/sbt-test/a/b/project/plugins.sbt
src/sbt-test/a/b/test
run
sbt scriptedproblem
Stack trace of
expectation
it should work
notes
xerial/sbt-sonatype#91
the
settingKey[T]macro takeOptJsonWriter[T]parameter.sbt.singleFileJsonFormatteradded since sbt 1.3.0-M3.3319423#diff-cafb18f4282f4fff753f9efb35169d46R41
The text was updated successfully, but these errors were encountered: