is there a company wide initiative to move everyone to gradle>5.4, IMO only removing some warnings by using @Replacedby doesn't fit as a good use-case to do an incompatible change. Maybe we merge this with 6.1 upgrade if and when we need it. wdyt?

Gradle 7.0 will be out soon and I plan to aggressively encourage upgrading to Gradle 5.6.4 at a minimum.

Nevertheless, as I mentioned above I could implement an alternative approach not requiring @ReplacedBy and leaving o.g.a.t.i.IncrementalTaskInputs in place for now:

An alternative to this PR would be to:

1. remove the methods annotated with @ReplacedBy, as they have been in a deprecated state for nearly two years, and
2. allow compiler warnings but only for the gradle-plugins subproject.

This makes the changes backward-compatible and buys some time, but at some point this plugin will have to use APIs which won't support older versions of Gradle.

This makes the changes backward-compatible and buys some time, but at some point this plugin will have to use APIs which won't support older versions of Gradle.

I would prefer deferring until we need to or there is some feature we would like to add available only in later versions because the cost of migrating consumers is high and we should have a greater incentive.

This makes the changes backward-compatible and buys some time, but at some point this plugin will have to use APIs which won't support older versions of Gradle.

I would prefer deferring until we need to or there is some feature we would like to add available only in later versions because the cost of migrating consumers is high and we should have a greater incentive.

Sounds fine. I will refactor to remove non-backwards-compatible changes.