Repository navigation
Todo list if/when we drop compat for an older Gradle version #504
Description
Activity
Aren't you still coupled to 2.14 for some internal projects you own?
Not anymore. However, I still don't see a reason to drop compat until Gradle starts throwing deprecation warnings for something that we are using which is required for 2.14. We just had a deep and long-standing bug get fixed by somebody who is stuck on Gradle 3.x
The just-released
google-java-format 1.8requires Java 11 (#563). Eclipse 4.17 (Sep 2020) is going to require Java 11 as well (#547). Gradle 5.0 is the first version of Gradle which supports running on Java 11.We normally keep the default versions of formatters set to their latest available versions (users can override), but now we're going to have to keep the defaults back for as long as we support Java 8.
As of now, the deprecated
IncrementalTaskInputsthat we use is scheduled to begin nagging in Gradle 7 - gradle/gradle#9048. Fixing that would bump our minimum required Gradle to5.4.I'm hoping we can get #280 and #511 resolved before that so they're available to people who are stuck on older Gradle for whatever reason.
I propose the following roadmap:
com.diffplug.gradle.spotless 4.x- goal: infrastructure necessary for buildcache, requires breaking minor public API, thus 4.x (Make spotless tasks all cacheable with the Gradle Build Cache #280, Separate the core
SpotlessTaskfrom check and apply #576, MakeFileSignaturemachine-independent. #566) - goal: support ratchet (Formatting ratchet #511), allows deprecating
-PspotlessFiles, I want this available for old Gradles
- goal: infrastructure necessary for buildcache, requires breaking minor public API, thus 4.x (Make spotless tasks all cacheable with the Gradle Build Cache #280, Separate the core
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
InputChangessince the old incremental API will nag in Gradle 7 which is coming soon - goal: use config avoidance (Eclipse 4.17 (2020-09) will require Java 11 #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 blahsince we need to bump to5.4very 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 to5.4sooner. I've got a prototype for #511 on my box, just wanted to get #576 merged first since it touches more things.Reacted by Jonathan Bluett-DuncanThe overall roadmap sounds great, Ned.
From my point of view, I'd be fine if the changes to make Spotless cacheable were all deferred until "ratchet" support was added and released for all versions of Gradle. I would be content to rework my PR to use
InputChangesand rebase on top of whatever changes come are required to support ratchet. (In fact, the #576 implementation may be cleaner withInputChanges, due to the availability ofFileChange.getNormalizedPath())I don't feel strongly about it, but I assume that deferring #576 (and related PRs) could avoid requiring 2 separate major releases. Since we're only talking about a few weeks delay, I don't see much downside.
Thanks! The other thing I failed to mention is that #576 makes #511 a lot easier! Part of why #511 is still sitting in a local stash is because of up-to-date challenges which you have fixed for me :) So I definitely want to merge and release #576 now.
I don’t mind bumping major version when the cost to our users is low or the benefit to them is high, and the cost of the 4.x bump incurred by #576 is very low. I’ve probably seemed like a stability-maximalist to people who have wanted us to adopt newer versions of Gradle, but I’m all for bumping major version when (benefit/cost) >> 1
Right, that makes sense then. Glad that my changes make developing other features easier.
I certainly think the new pattern is easier to extend, and easier for my brain to process :).@jbduncan @fvgh do you have any objections to the roadmap above? I've got 4.0 ready to ship, but I wanted to make sure that you two are okay with that plan before I take any irreversible steps in that direction.
Small change to the roadmap. During the 4.x train, we will ship
com.diffplug.gradle.spotless(gradle 2.x+) and an incubating version ofcom.diffplug.spotless(gradle 5.4+) in the same jar. I've got a PoC branch which lets us run our existing test suite against both, so that we can be confident that we're not breaking anything on accident. I expect to get that up today.The change to
com.diffplug.spotlessis an especially good time to look at how we definetarget. It's grown somewhat complex, and there have been some valid issues raised by people, which we have closed aswontfixdue to backcompat. While both plugins live in the same jar, we have a unique opportunity to do something likespotless5xMigrationCheck, where we could change the target behavior, and allow users to confirm that they have adjusted their project to format all the same files as before.Just wanted to drop you a line @fvgh and @jbduncan. I just released
lib 2.0.0andplugin-maven 2.0.0. The next project will be to strip all the deprecated code fromplugin-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.
Reacted by Jonathan Bluett-Duncan
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.roottoext.Remove
GradleProvisioner.fromProject(Project project)(should make the whole class package-private, probably)Standardize win-detection