fix references to 9.0 (#34634)

big-guy · web-flow · commit b21e32ac5950 · 2025-08-12T18:45:43.000Z
diff --git a/platforms/documentation/docs/src/docs/userguide/integration/tooling_api.adoc b/platforms/documentation/docs/src/docs/userguide/integration/tooling_api.adoc
@@ -94,6 +94,6 @@ The rule for the lower bound is the following:
 - Gradle 5 and above require a minimum version of Java 8.
 
 The Tooling API version is guaranteed to support running builds with all Gradle versions for the last five major releases.
-For example, the Tooling API 9.0 release is compatible with Gradle versions >= 4.0.
+For example, the Tooling API 9.0.0 release is compatible with Gradle versions >= 4.0.
 Besides, the Tooling API is guaranteed to be compatible with future Gradle releases for the current and the next major.
 This means, for example, that the 8.1 version of the Tooling API will be able to run Gradle 9.x builds and _might_ break with Gradle 10.
diff --git a/platforms/documentation/docs/src/docs/userguide/optimizing-builds/build-cache/common_caching_problems.adoc b/platforms/documentation/docs/src/docs/userguide/optimizing-builds/build-cache/common_caching_problems.adoc
@@ -233,7 +233,7 @@ A task depending on this task output would then not be able to load outputs from
 As described in the <<build_cache_concepts.adoc#stable_task_inputs,stable task inputs section>>, you can either make the task outputs repeatable or use input normalization.
 You already learned about the possibilities with <<build_cache_concepts.adoc#filter_runtime_classpath,configurable input normalization>>.
 
-Tasks that produce archives (`tar`, `zip`) are <<working_with_files.adoc#sec:reproducible_archives,reproducible>> by default, starting with Gradle 9.0.
+Tasks that produce archives (`tar`, `zip`) are <<working_with_files.adoc#sec:reproducible_archives,reproducible>> by default, starting with Gradle 9.0.0.
 For earlier Gradle versions or if you want explicit configuration, you can make archives reproducible configuring a task in the following way:
 
 ====
diff --git a/platforms/documentation/docs/src/docs/userguide/optimizing-builds/configuration-cache/configuration_cache.adoc b/platforms/documentation/docs/src/docs/userguide/optimizing-builds/configuration-cache/configuration_cache.adoc
@@ -68,7 +68,7 @@ This feature is _not enabled by default_ and has the following limitations:
 - <<config_cache:ide,IDE imports and syncs>> do not yet use the Configuration Cache.
 - Continuous Integration (CI) support is actively evolving.
 
-Since Gradle 9.0 the Configuration Cache is the link:https://blog.gradle.org/road-to-configuration-cache#preferred-mode-of-execution[preferred mode of execution].
+Since Gradle 9.0.0 the Configuration Cache is the link:https://blog.gradle.org/road-to-configuration-cache#preferred-mode-of-execution[preferred mode of execution].
 ====
 
 [[config_cache:intro:how_does_it_work]]
diff --git a/platforms/documentation/docs/src/docs/userguide/optimizing-builds/configuration-cache/configuration_cache_enabling.adoc b/platforms/documentation/docs/src/docs/userguide/optimizing-builds/configuration-cache/configuration_cache_enabling.adoc
@@ -353,7 +353,7 @@ To temporarily revert to the previous behavior, set the Gradle property `org.gra
 With the evolution of the Configuration Cache, Gradle may impose additional restrictions on build logic.
 To make adoption smoother, it is possible to _temporarily_ opt out of these restrictions in specific cases:
 
-1. Starting with Gradle 9.0, it is an error to use any provider, except a provider of `BuildService` returned from
+1. Starting with Gradle 9.0.0, it is an error to use any provider, except a provider of `BuildService` returned from
 link:{javadocPath}/org/gradle/api/services/BuildServiceRegistry.html#registerIfAbsent(java.lang.String,java.lang.Class,org.gradle.api.Action)[`BuildServiceRegistry.registerIfAbsent`]
 or
 link:{javadocPath}/org/gradle/api/services/BuildServiceRegistration.html#getService()[`BuildServiceRegistration.getService`]
diff --git a/platforms/documentation/docs/src/docs/userguide/reference/gradle-types/working_with_files.adoc b/platforms/documentation/docs/src/docs/userguide/reference/gradle-types/working_with_files.adoc
@@ -1024,7 +1024,7 @@ Reproducing the same byte-for-byte archive generally poses some challenges since
 Each time a ZIP, TAR, JAR, WAR or EAR is built from source, the order of the files inside the archive may change.
 Files on disk can also have different timestamps or permissions depending on the environment.
 
-Starting with Gradle 9.0, all link:{groovyDslPath}/org.gradle.api.tasks.bundling.AbstractArchiveTask.html[AbstractArchiveTask] (e.g. `Jar`, `Zip`) tasks produce reproducible archives by default:
+Starting with Gradle 9.0.0, all link:{groovyDslPath}/org.gradle.api.tasks.bundling.AbstractArchiveTask.html[AbstractArchiveTask] (e.g. `Jar`, `Zip`) tasks produce reproducible archives by default:
 
 - File order in the archive is deterministic
 - Files have fixed timestamps (exact values depend on the archive type)
diff --git a/platforms/documentation/docs/src/docs/userguide/reference/structuring-builds/multi_project_builds.adoc b/platforms/documentation/docs/src/docs/userguide/reference/structuring-builds/multi_project_builds.adoc
@@ -130,7 +130,7 @@ NOTE: Setting the link:{groovyDslPath}/org.gradle.api.Project.html#org.gradle.ap
 
 When you include a subproject in your `settings.gradle(.kts)` file, Gradle expects that the associated directory for that project exists and is writable.
 
-WARNING: Starting with **Gradle 9.0**, this is enforced strictly: **If a project directory is missing or read-only, the build will fail.** This replaces earlier behavior where Gradle would silently allow missing project directories.
+WARNING: Starting with **Gradle 9.0.0**, this is enforced strictly: **If a project directory is missing or read-only, the build will fail.** This replaces earlier behavior where Gradle would silently allow missing project directories.
 
 Here's how you can create a missing directory at configuration time:
 
diff --git a/platforms/documentation/docs/src/docs/userguide/releases/compatibility.adoc b/platforms/documentation/docs/src/docs/userguide/releases/compatibility.adoc
@@ -101,7 +101,7 @@ Beta and RC versions may or may not work.
 | 1.9.24 | 8.10 | 1.8
 | 2.0.20 | 8.11 | 1.8
 | 2.0.21 | 8.12 | 1.8
-| 2.2.0  | 9.0 | 2.2
+| 2.2.0  | 9.0.0 | 2.2
 |===
 
 == Groovy
diff --git a/platforms/documentation/docs/src/docs/userguide/releases/upgrading/upgrading_major_version_9.adoc b/platforms/documentation/docs/src/docs/userguide/releases/upgrading/upgrading_major_version_9.adoc
@@ -324,7 +324,7 @@ If you are already applying one of those, no further action is needed.
 
 NOTE: This change may affect existing builds that relied on the previous behavior of archive tasks, where file order was not deterministic, and file timestamps and permissions were taken from the file system.
 
-In Gradle 9.0, the default behavior of archive tasks (such as `Jar`, `Ear`, `War`, `Zip`, and `AbstractArchiveTask`) has changed to produce reproducible archives by default.
+In Gradle 9.0.0, the default behavior of archive tasks (such as `Jar`, `Ear`, `War`, `Zip`, and `AbstractArchiveTask`) has changed to produce reproducible archives by default.
 That means that:
 
 - File order in the archive is now deterministic.
diff --git a/platforms/documentation/docs/src/docs/userguide/releases/upgrading/upgrading_version_7.adoc b/platforms/documentation/docs/src/docs/userguide/releases/upgrading/upgrading_version_7.adoc
@@ -221,7 +221,7 @@ Use the `archiveAppendix`, `archiveFileName` , `archiveFile`, `archiveBaseName`,
 ==== AbstractCompile API Deprecations
 
 The previously deprecated `destinationDir` property of the `AbstractCompile` remains deprecated, and will now emit a deprecation warning upon use.
-It is now scheduled for removal in Gradle 9.0.
+It is now scheduled for removal in Gradle 9.0.0.
 Use the `destinationDirectory` property instead.
 
 ==== ResolvedComponentResult API Cleanup
@@ -675,7 +675,7 @@ No changes are required for projects that already apply the
 
 ==== Upload Task should not be used
 
-The `Upload` task remains deprecated and is now scheduled for removal in Gradle 9.0.
+The `Upload` task remains deprecated and is now scheduled for removal in Gradle 9.0.0.
 Although this type remains, it is no longer functional and will throw an exception upon running.
 It is preserved solely to avoid breaking plugins.
 Use the tasks in the `maven-publish` or `ivy-publish` plugins instead.
@@ -881,7 +881,7 @@ See more details about toolchain configuration in the <<toolchains#sec:configuri
 [[org_gradle_util_reports_deprecations_7]]
 ==== Deprecated members of the `org.gradle.util` package now report their deprecation
 
-These members will be removed in Gradle 9.0.
+These members will be removed in Gradle 9.0.0.
 
 * `ClosureBackedAction`
 * `CollectionUtils`
@@ -1303,7 +1303,7 @@ If the set of attributes is shared across configurations, consider adding an add
 [[for_use_at_configuration_time_deprecation]]
 ==== `Provider#forUseAtConfigurationTime()` has been deprecated
 
-link:{javadocPath}/org/gradle/api/provider/Provider.html#forUseAtConfigurationTime--[Provider#forUseAtConfigurationTime] is now deprecated and scheduled for removal in Gradle 9.0.
+link:{javadocPath}/org/gradle/api/provider/Provider.html#forUseAtConfigurationTime--[Provider#forUseAtConfigurationTime] is now deprecated and scheduled for removal in Gradle 9.0.0.
 Clients should simply remove the call.
 
 The call was mandatory on providers of external values such as link:{groovyDslPath}/org.gradle.api.provider.ProviderFactory.html#org.gradle.api.provider.ProviderFactory:systemProperty(java.lang.String)[system properties], link:{groovyDslPath}/org.gradle.api.provider.ProviderFactory.html#org.gradle.api.provider.ProviderFactory:environmentVariable(java.lang.String)[environment variables],
diff --git a/platforms/documentation/docs/src/docs/userguide/releases/upgrading/upgrading_version_8.adoc b/platforms/documentation/docs/src/docs/userguide/releases/upgrading/upgrading_version_8.adoc
diff --git a/platforms/documentation/docs/src/docs/userguide/releases/upgrading/upgrading_version_9.adoc b/platforms/documentation/docs/src/docs/userguide/releases/upgrading/upgrading_version_9.adoc
