checkstyle is the same, I believe. But there I understand why, because it's bundled with gradle it has to provide a way to utilize older rules configuration with newer checkstyle to avoid breaking the checks when gradle is upgraded.
With detekt I do not see the rationale, maybe one of the authors would like to comment.
Czar
05/15/2018, 11:20 PM
Hm... actually maybe if config format changed between versions, but latest version has better performance even with old config 🤔
x
xenomachina
05/15/2018, 11:49 PM
Interesting thought! Seems like a bit of a stretch though. What's the chance that the gradle config would change in a way that's not backwards compatible, but the interface the plugin uses to talk to detekt remains backwards compatible?
a
Artur Bosch
05/17/2018, 8:32 PM
There are not that many changes to the gradle plugin then to detekt-cli. Half of detekt's version could have been released without a new version of the gradle plugin.
Don't know yet if we should always update the gradle-plugin just to be on pair with the version scheme 🙂
x
xenomachina
05/18/2018, 9:09 PM
I suspect that that's a pretty common situation for plugins that depend on underlying tools. As long as the interface to the underlying tool hasn't changed, the actual code of the plugin doesn't need to change, but I think many plugins release anyway, just to simplify version management.
xenomachina
05/18/2018, 9:15 PM
I just checked kotlin-gradle-plugin going back to 1.0.0, and it looks like many of the versions have exactly the same source as their previous version. I think they release a new version of the plugin even when the only thing that has changed is the kotlin compiler and/or runtime.