Todo list if/when we drop compat for an older Gradle version

To my knowledge, the only thing we’re sacrificing by maintaining support for 2.14 is task configuration avoidance. We do this internally already, so we don’t have much to gain from adopting it. But I figured I’d make a central place to keep track of where we’re not using the latest APIs, and other changes we can make when/if we cut ties with older versions.

• Gradle 4.9 added task config avoidance

• Gradle 5.4 added new incremental task input API

• Rename FormatExtension.root to ext.

• Remove GradleProvisioner.fromProject(Project project) (should make the whole class package-private, probably)

• Standardize win-detection

[nedtwigg]

Just wanted to drop you a line @fvgh and @jbduncan. I just released lib 2.0.0 and plugin-maven 2.0.0. The next project will be to strip all the deprecated code from plugin-gradle. I did a rehash of our docs, which exposed some inconsistencies, which led me to believe that we should cut some small things (namely default targets, but some other small things too).

If there’s anything that I cut, which you would like to be put back, I’m 100% open to putting it back! Since we had to take a breaking change in order to fix some caching issues, and we can always add them back without a breaking change, I leaned towards “cut it” for things where I was on the fence.

[nedtwigg]

I propose the following roadmap:

• com.diffplug.gradle.spotless 4.x
  • goal: infrastructure necessary for buildcache, requires breaking minor public API, thus 4.x (#280, #576, #566)
  • goal: support ratchet (#511), allows deprecating -PspotlessFiles, I want this available for old Gradles
• com.diffplug.spotless 5.0, release by June 1st at latest
  • goal: remove all deprecated functionality
  • goal: remove redundant “gradle” from plugin id (rant)
  • goal: bump Gradle minimum to 5.4 so we can use the new InputChanges since the old incremental API will nag in Gradle 7 which is coming soon
  • goal: use config avoidance (#547)

The “goals” in each phase are loose. One of my top priorities personally is to not be a blocker on other people’s work, so if a good PR ready to ship then we’ll ship it, major versions be damned. But I’d like to get #511 out and available all the way back to 2.x. IMO, it removes every single excuse to not use an autoformatter, no matter what version of Gradle you might be stuck on.

I also want to minimize the if gradleOld then blah since we need to bump to 5.4 very soon anyway. So I’m asking for a stay until June 1st at the latest. Once June 1st comes around, we’ll set Gradle 5.4 as the minimum supported, and it’ll be open season to adopt all of Gradle’s latest and greatest. If I can get #511 merged sooner, then we’ll bump minimum-required to 5.4 sooner. I’ve got a prototype for #511 on my box, just wanted to get #576 merged first since it touches more things.