anchor.diff:  * [[task_configuration_avoidance_pitfall_build_scan_plugin]] **The build scan plugin `buildScanPublishPrevious` task is eager until version 1.15.** Upgrade the build scan plugin in your build to use the latest version.
   
   [[sec:task_configuration_avoidance_backward_compatibility_migration]]
  -==== How to keep backward compatibility for plugin authors?
  -
  -Plugin authors may have additional obligation regarding backward compatibility.
  -This section explains two ways for plugin authors to keep their plugins backward compatible with older version of Gradle.
  +==== Supporting older versions of Gradle
  +
  +This section describes two ways to keep your plugin backward compatible with older version of Gradle if you must maintain compatibility with versions of Gradle older than 4.9.
   
   [NOTE]
   ====
  -Although allowing your plugin to be backward compatible is good for the users, it is still recommended to move compatibility forward to Gradle 4.9+ sooner rather than later.
  -====
  -
  -The first method is to compile your plugin against the Gradle 4.9 API and https://github.com/melix/jmh-gradle-plugin/blob/a034aa88805b7a06fa9c5a825d573554b2aa23e2/src/main/groovy/me/champeau/gradle/JMHPlugin.groovy#L289-L296[conditionally call the right APIs], i.e. `TaskContainer#create` vs. `TaskContainer#register` where required.
  -This method is highly preferred to the alternative.
  -
  -The second method is to use Java reflection to cop with the fact that the APIs are unavailable during compilation.
  -This method as several performance pitfalls that may be undesired for your users.
  -
  -It is highly recommended to have sufficient cross-version test coverage using <<test_kit, TestKit>>.
  +Although backward compatibility is good for users, we still recommended to upgrade to newer Gradle releases in a timely manner. This will reduce your maintenance burden.
  +====
  +
  +The first method to maintain compatibility is to compile your plugin against the Gradle 4.9 API and conditionally call the right APIs with Groovy (https://github.com/melix/jmh-gradle-plugin/blob/a034aa88805b7a06fa9c5a825d573554b2aa23e2/src/main/groovy/me/champeau/gradle/JMHPlugin.groovy#L289-L296[example]). 
  +
  +The second method is to use Java reflection to cope with the fact that the APIs are unavailable during compilation (https://github.com/tbroyer/gradle-apt-plugin/tree/432509ec85d1ab49296d4f9b21fad876523c6a8a/src/main/java/net/ltgt/gradle/apt[example]).
  +
  +It is highly recommended to have cross-version test coverage using <<test_kit.adoc#sub:gradle-runner-gradle-version, TestKit>> and multiple versions of Gradle.
   
   [[sec:old_vs_new_configuration_api_overview]]
   == Old vs New API overview
  
positive.code: It’s unfortunate, and we feel your frustration. Keep reading onto the next section.
  
  [[sec:task_configuration_avoidance_troubleshooting]]
  ==== Troubleshooting
  * **The build became unstable after migrating to lazy task configuration.**
  It’s a common issue that happens during the migration.
  Follow these next steps to find out the issue:
  
negative.code: To approximate the time it takes to configure a build without executing tasks, you can run `gradle help`. Please use the Gradle Profiler to measure your build as described <<#sec:new_task_gradle_profiler_scenario,further on>>.
  
  [[sec:task_configuration_avoidance_migration_guidelines]]
  == Migration Guide
  
  The following sections will go through some <<#sec:task_configuration_avoidance_general, general guidelines>> to adhere when migrating the build logic as well as <<#sec:task_configuration_avoidance_migration_steps, the steps>> we recommend following.
  We also cover some <<#sec:task_configuration_avoidance_troubleshooting, troubleshooting>> and <<#sec:task_configuration_avoidance_pitfalls, pitfalls>> to help you work around some issues you may encountered during the migration.
  
  [[sec:task_configuration_avoidance_general]]
  === General
  1. [[task_configuration_avoidance_guideline_use_help_task]] **Use `help` task as a benchmark during the migration.**
  The `help` task is the perfect candidate to benchmark your migration process.
  In a completely lazy build, https://scans.gradle.com/s/o7qmlmmrsfxz4/performance/configuration?openScriptsAndPlugins=WzFd[a build scan should show no task created immediately or created during configuration].
  