From a8e8897a000573bb32ea3415e052c54c4ab9223d Mon Sep 17 00:00:00 2001
From: Sam Brannen <104798+sbrannen@users.noreply.github.com>
Date: Mon, 1 Jul 2024 18:37:46 +0200
Subject: [PATCH] Stop referring to old Spring versions in the reference manual

---
 .../modules/ROOT/pages/core/aop/ataspectj/advice.adoc |  2 +-
 .../pages/core/beans/annotation-config/autowired.adoc |  6 +++---
 .../ROOT/pages/core/beans/classpath-scanning.adoc     |  2 +-
 .../modules/ROOT/pages/core/spring-jcl.adoc           |  2 +-
 .../modules/ROOT/pages/data-access/orm/hibernate.adoc |  4 ++--
 .../transaction/declarative/rolling-back.adoc         |  4 ++--
 .../pages/data-access/transaction/strategies.adoc     |  6 +++---
 .../ROOT/pages/languages/kotlin/coroutines.adoc       |  2 +-
 .../annotations/integration-junit-jupiter.adoc        | 11 +++++------
 .../testcontext-framework/application-events.adoc     |  2 +-
 .../ctx-management/env-profiles.adoc                  |  4 ++--
 .../ctx-management/inheritance.adoc                   |  4 ++--
 .../ctx-management/property-sources.adoc              |  7 ++++---
 .../testing/testcontext-framework/executing-sql.adoc  |  2 +-
 .../testcontext-framework/support-classes.adoc        |  8 ++------
 .../testcontext-framework/test-execution-events.adoc  |  6 +++---
 16 files changed, 34 insertions(+), 38 deletions(-)

diff --git a/framework-docs/modules/ROOT/pages/core/aop/ataspectj/advice.adoc b/framework-docs/modules/ROOT/pages/core/aop/ataspectj/advice.adoc
index 55c3b91466..039bc862a8 100644
--- a/framework-docs/modules/ROOT/pages/core/aop/ataspectj/advice.adoc
+++ b/framework-docs/modules/ROOT/pages/core/aop/ataspectj/advice.adoc
@@ -923,7 +923,7 @@ Each of the distinct advice types of a particular aspect is conceptually meant t
 to the join point directly. As a consequence, an `@AfterThrowing` advice method is not
 supposed to receive an exception from an accompanying `@After`/`@AfterReturning` method.
 
-As of Spring Framework 5.2.7, advice methods defined in the same `@Aspect` class that
+Advice methods defined in the same `@Aspect` class that
 need to run at the same join point are assigned precedence based on their advice type in
 the following order, from highest to lowest precedence: `@Around`, `@Before`, `@After`,
 `@AfterReturning`, `@AfterThrowing`. Note, however, that an `@After` advice method will
diff --git a/framework-docs/modules/ROOT/pages/core/beans/annotation-config/autowired.adoc b/framework-docs/modules/ROOT/pages/core/beans/annotation-config/autowired.adoc
index fcf7465426..8470dd91c2 100644
--- a/framework-docs/modules/ROOT/pages/core/beans/annotation-config/autowired.adoc
+++ b/framework-docs/modules/ROOT/pages/core/beans/annotation-config/autowired.adoc
@@ -421,9 +421,9 @@ through Java 8's `java.util.Optional`, as the following example shows:
 	}
 ----
 
-As of Spring Framework 5.0, you can also use a `@Nullable` annotation (of any kind
-in any package -- for example, `javax.annotation.Nullable` from JSR-305) or just leverage
-Kotlin built-in null-safety support:
+You can also use a `@Nullable` annotation (of any kind in any package -- for example,
+`javax.annotation.Nullable` from JSR-305) or just leverage Kotlin built-in null-safety
+support:
 
 [tabs]
 ======
diff --git a/framework-docs/modules/ROOT/pages/core/beans/classpath-scanning.adoc b/framework-docs/modules/ROOT/pages/core/beans/classpath-scanning.adoc
index 85d354a82c..4f98a935f8 100644
--- a/framework-docs/modules/ROOT/pages/core/beans/classpath-scanning.adoc
+++ b/framework-docs/modules/ROOT/pages/core/beans/classpath-scanning.adoc
@@ -751,7 +751,7 @@ and bean definition show.
 TIP: If you run into naming conflicts due to multiple autodetected components having the
 same non-qualified class name (i.e., classes with identical names but residing in
 different packages), you may need to configure a `BeanNameGenerator` that defaults to the
-fully qualified class name for the generated bean name. As of Spring Framework 5.2.3, the
+fully qualified class name for the generated bean name. The
 `FullyQualifiedAnnotationBeanNameGenerator` located in package
 `org.springframework.context.annotation` can be used for such purposes.
 
diff --git a/framework-docs/modules/ROOT/pages/core/spring-jcl.adoc b/framework-docs/modules/ROOT/pages/core/spring-jcl.adoc
index 67e9d1d317..419338ffed 100644
--- a/framework-docs/modules/ROOT/pages/core/spring-jcl.adoc
+++ b/framework-docs/modules/ROOT/pages/core/spring-jcl.adoc
@@ -1,7 +1,7 @@
 [[spring-jcl]]
 = Logging
 
-Since Spring Framework 5.0, Spring comes with its own Commons Logging bridge implemented
+Spring comes with its own Commons Logging bridge implemented
 in the `spring-jcl` module. The implementation checks for the presence of the Log4j 2.x
 API and the SLF4J 1.7 API in the classpath and uses the first one of those found as the
 logging implementation, falling back to the Java platform's core logging facilities (also
diff --git a/framework-docs/modules/ROOT/pages/data-access/orm/hibernate.adoc b/framework-docs/modules/ROOT/pages/data-access/orm/hibernate.adoc
index 45328b85cd..b8a3704018 100644
--- a/framework-docs/modules/ROOT/pages/data-access/orm/hibernate.adoc
+++ b/framework-docs/modules/ROOT/pages/data-access/orm/hibernate.adoc
@@ -87,8 +87,8 @@ On `LocalSessionFactoryBean`, this is available through the `bootstrapExecutor`
 property. On the programmatic `LocalSessionFactoryBuilder`, there is an overloaded
 `buildSessionFactory` method that takes a bootstrap executor argument.
 
-As of Spring Framework 5.1, such a native Hibernate setup can also expose a JPA
-`EntityManagerFactory` for standard JPA interaction next to native Hibernate access.
+Such a native Hibernate setup can also expose a JPA `EntityManagerFactory` for standard
+JPA interaction next to native Hibernate access.
 See xref:data-access/orm/jpa.adoc#orm-jpa-hibernate[Native Hibernate Setup for JPA] for details.
 ====
 
diff --git a/framework-docs/modules/ROOT/pages/data-access/transaction/declarative/rolling-back.adoc b/framework-docs/modules/ROOT/pages/data-access/transaction/declarative/rolling-back.adoc
index 166fb73243..355365fb27 100644
--- a/framework-docs/modules/ROOT/pages/data-access/transaction/declarative/rolling-back.adoc
+++ b/framework-docs/modules/ROOT/pages/data-access/transaction/declarative/rolling-back.adoc
@@ -19,8 +19,8 @@ marks a transaction for rollback only in the case of runtime, unchecked exceptio
 That is, when the thrown exception is an instance or subclass of `RuntimeException`.
 (`Error` instances also, by default, result in a rollback).
 
-As of Spring Framework 5.2, the default configuration also provides support for
-Vavr's `Try` method to trigger transaction rollbacks when it returns a 'Failure'.
+The default configuration also provides support for Vavr's `Try` method to trigger
+transaction rollbacks when it returns a 'Failure'.
 This allows you to handle functional-style errors using Try and have the transaction
 automatically rolled back in case of a failure. For more information on Vavr's Try,
 refer to the https://docs.vavr.io/#_try[official Vavr documentation].
diff --git a/framework-docs/modules/ROOT/pages/data-access/transaction/strategies.adoc b/framework-docs/modules/ROOT/pages/data-access/transaction/strategies.adoc
index d64cef5a2b..d052af9dd6 100644
--- a/framework-docs/modules/ROOT/pages/data-access/transaction/strategies.adoc
+++ b/framework-docs/modules/ROOT/pages/data-access/transaction/strategies.adoc
@@ -45,9 +45,9 @@ exists in the current call stack. The implication in this latter case is that, a
 Jakarta EE transaction contexts, a `TransactionStatus` is associated with a thread of
 execution.
 
-As of Spring Framework 5.2, Spring also provides a transaction management abstraction for
-reactive applications that make use of reactive types or Kotlin Coroutines. The following
-listing shows the transaction strategy defined by
+Spring also provides a transaction management abstraction for reactive applications that
+make use of reactive types or Kotlin Coroutines. The following listing shows the
+transaction strategy defined by
 `org.springframework.transaction.ReactiveTransactionManager`:
 
 [source,java,indent=0,subs="verbatim,quotes"]
diff --git a/framework-docs/modules/ROOT/pages/languages/kotlin/coroutines.adoc b/framework-docs/modules/ROOT/pages/languages/kotlin/coroutines.adoc
index 913acb052e..9e09a69411 100644
--- a/framework-docs/modules/ROOT/pages/languages/kotlin/coroutines.adoc
+++ b/framework-docs/modules/ROOT/pages/languages/kotlin/coroutines.adoc
@@ -209,7 +209,7 @@ class UserHandler(builder: WebClient.Builder) {
 == Transactions
 
 Transactions on Coroutines are supported via the programmatic variant of the Reactive
-transaction management provided as of Spring Framework 5.2.
+transaction management.
 
 For suspending functions, a `TransactionalOperator.executeAndAwait` extension is provided.
 
diff --git a/framework-docs/modules/ROOT/pages/testing/annotations/integration-junit-jupiter.adoc b/framework-docs/modules/ROOT/pages/testing/annotations/integration-junit-jupiter.adoc
index 64af8240b8..75e85b861e 100644
--- a/framework-docs/modules/ROOT/pages/testing/annotations/integration-junit-jupiter.adoc
+++ b/framework-docs/modules/ROOT/pages/testing/annotations/integration-junit-jupiter.adoc
@@ -183,18 +183,17 @@ The default _test constructor autowire mode_ can be changed by setting the
 default mode may be set via the
 xref:appendix.adoc#appendix-spring-properties[`SpringProperties`] mechanism.
 
-As of Spring Framework 5.3, the default mode may also be configured as a
+The default mode may also be configured as a
 https://junit.org/junit5/docs/current/user-guide/#running-tests-config-params[JUnit Platform configuration parameter].
 
 If the `spring.test.constructor.autowire.mode` property is not set, test class
 constructors will not be automatically autowired.
 =====
 
-NOTE: As of Spring Framework 5.2, `@TestConstructor` is only supported in conjunction
-with the `SpringExtension` for use with JUnit Jupiter. Note that the `SpringExtension` is
-often automatically registered for you – for example, when using annotations such as
-`@SpringJUnitConfig` and `@SpringJUnitWebConfig` or various test-related annotations from
-Spring Boot Test.
+NOTE: `@TestConstructor` is only supported in conjunction with the `SpringExtension` for
+use with JUnit Jupiter. Note that the `SpringExtension` is often automatically registered
+for you – for example, when using annotations such as `@SpringJUnitConfig` and
+`@SpringJUnitWebConfig` or various test-related annotations from Spring Boot Test.
 
 [[integration-testing-annotations-nestedtestconfiguration]]
 == `@NestedTestConfiguration`
diff --git a/framework-docs/modules/ROOT/pages/testing/testcontext-framework/application-events.adoc b/framework-docs/modules/ROOT/pages/testing/testcontext-framework/application-events.adoc
index b27d2d98c5..41abfb7b06 100644
--- a/framework-docs/modules/ROOT/pages/testing/testcontext-framework/application-events.adoc
+++ b/framework-docs/modules/ROOT/pages/testing/testcontext-framework/application-events.adoc
@@ -1,7 +1,7 @@
 [[testcontext-application-events]]
 = Application Events
 
-Since Spring Framework 5.3.3, the TestContext framework provides support for recording
+The TestContext framework provides support for recording
 xref:core/beans/context-introduction.adoc#context-functionality-events[application events] published in the
 `ApplicationContext` so that assertions can be performed against those events within
 tests. All events published during the execution of a single test are made available via
diff --git a/framework-docs/modules/ROOT/pages/testing/testcontext-framework/ctx-management/env-profiles.adoc b/framework-docs/modules/ROOT/pages/testing/testcontext-framework/ctx-management/env-profiles.adoc
index f1d52d53c0..aebdfa867b 100644
--- a/framework-docs/modules/ROOT/pages/testing/testcontext-framework/ctx-management/env-profiles.adoc
+++ b/framework-docs/modules/ROOT/pages/testing/testcontext-framework/ctx-management/env-profiles.adoc
@@ -366,8 +366,8 @@ automatically inherit the `@ActiveProfiles` configuration from the base class. I
 following example, the declaration of `@ActiveProfiles` (as well as other annotations)
 has been moved to an abstract superclass, `AbstractIntegrationTest`:
 
-NOTE: As of Spring Framework 5.3, test configuration may also be inherited from enclosing
-classes. See xref:testing/testcontext-framework/support-classes.adoc#testcontext-junit-jupiter-nested-test-configuration[`@Nested` test class configuration] for details.
+NOTE: Test configuration may also be inherited from enclosing classes. See
+xref:testing/testcontext-framework/support-classes.adoc#testcontext-junit-jupiter-nested-test-configuration[`@Nested` test class configuration] for details.
 
 [tabs]
 ======
diff --git a/framework-docs/modules/ROOT/pages/testing/testcontext-framework/ctx-management/inheritance.adoc b/framework-docs/modules/ROOT/pages/testing/testcontext-framework/ctx-management/inheritance.adoc
index 0ca98c0965..72779aa2b3 100644
--- a/framework-docs/modules/ROOT/pages/testing/testcontext-framework/ctx-management/inheritance.adoc
+++ b/framework-docs/modules/ROOT/pages/testing/testcontext-framework/ctx-management/inheritance.adoc
@@ -17,8 +17,8 @@ is set to `false`, the resource locations or component classes and the context
 initializers, respectively, for the test class shadow and effectively replace the
 configuration defined by superclasses.
 
-NOTE: As of Spring Framework 5.3, test configuration may also be inherited from enclosing
-classes. See xref:testing/testcontext-framework/support-classes.adoc#testcontext-junit-jupiter-nested-test-configuration[`@Nested` test class configuration] for details.
+NOTE: Test configuration may also be inherited from enclosing classes. See
+xref:testing/testcontext-framework/support-classes.adoc#testcontext-junit-jupiter-nested-test-configuration[`@Nested` test class configuration] for details.
 
 In the next example, which uses XML resource locations, the `ApplicationContext` for
 `ExtendedTest` is loaded from `base-config.xml` and `extended-config.xml`, in that order.
diff --git a/framework-docs/modules/ROOT/pages/testing/testcontext-framework/ctx-management/property-sources.adoc b/framework-docs/modules/ROOT/pages/testing/testcontext-framework/ctx-management/property-sources.adoc
index bb83c4d4da..0af5d6cbf4 100644
--- a/framework-docs/modules/ROOT/pages/testing/testcontext-framework/ctx-management/property-sources.adoc
+++ b/framework-docs/modules/ROOT/pages/testing/testcontext-framework/ctx-management/property-sources.adoc
@@ -168,7 +168,8 @@ Kotlin::
 
 [NOTE]
 ====
-As of Spring Framework 5.2, `@TestPropertySource` can be used as _repeatable annotation_.
+`@TestPropertySource` can be used as _repeatable annotation_.
+
 That means that you can have multiple declarations of `@TestPropertySource` on a single
 test class, with the `locations` and `properties` from later `@TestPropertySource`
 annotations overriding those from previous `@TestPropertySource` annotations.
@@ -261,8 +262,8 @@ If the `inheritLocations` or `inheritProperties` attribute in `@TestPropertySour
 set to `false`, the locations or inlined properties, respectively, for the test class
 shadow and effectively replace the configuration defined by superclasses.
 
-NOTE: As of Spring Framework 5.3, test configuration may also be inherited from enclosing
-classes. See xref:testing/testcontext-framework/support-classes.adoc#testcontext-junit-jupiter-nested-test-configuration[`@Nested` test class configuration] for details.
+NOTE: Test configuration may also be inherited from enclosing classes. See
+xref:testing/testcontext-framework/support-classes.adoc#testcontext-junit-jupiter-nested-test-configuration[`@Nested` test class configuration] for details.
 
 In the next example, the `ApplicationContext` for `BaseTest` is loaded by using only the
 `base.properties` file as a test property source. In contrast, the `ApplicationContext`
diff --git a/framework-docs/modules/ROOT/pages/testing/testcontext-framework/executing-sql.adoc b/framework-docs/modules/ROOT/pages/testing/testcontext-framework/executing-sql.adoc
index b3bd66ff7c..62f432faf1 100644
--- a/framework-docs/modules/ROOT/pages/testing/testcontext-framework/executing-sql.adoc
+++ b/framework-docs/modules/ROOT/pages/testing/testcontext-framework/executing-sql.adoc
@@ -495,7 +495,7 @@ details).
 [[testcontext-executing-sql-declaratively-script-merging]]
 === Merging and Overriding Configuration with `@SqlMergeMode`
 
-As of Spring Framework 5.2, it is possible to merge method-level `@Sql` declarations with
+It is possible to merge method-level `@Sql` declarations with
 class-level declarations. For example, this allows you to provide the configuration for a
 database schema or some common test data once per test class and then provide additional,
 use case specific test data per test method. To enable `@Sql` merging, annotate either
diff --git a/framework-docs/modules/ROOT/pages/testing/testcontext-framework/support-classes.adoc b/framework-docs/modules/ROOT/pages/testing/testcontext-framework/support-classes.adoc
index 5173116682..e3257f334a 100644
--- a/framework-docs/modules/ROOT/pages/testing/testcontext-framework/support-classes.adoc
+++ b/framework-docs/modules/ROOT/pages/testing/testcontext-framework/support-classes.adoc
@@ -531,12 +531,8 @@ to the `RepetitionInfo`.
 [[testcontext-junit-jupiter-nested-test-configuration]]
 === `@Nested` test class configuration
 
-The _Spring TestContext Framework_ has supported the use of test-related annotations on
-`@Nested` test classes in JUnit Jupiter since Spring Framework 5.0; however, until Spring
-Framework 5.3 class-level test configuration annotations were not _inherited_ from
-enclosing classes like they are from superclasses.
-
-Spring Framework 5.3 introduced first-class support for inheriting test class
+The _Spring TestContext Framework_ supports the use of test-related annotations on `@Nested`
+test classes in JUnit Jupiter, including first-class support for inheriting test class
 configuration from enclosing classes, and such configuration will be inherited by
 default. To change from the default `INHERIT` mode to `OVERRIDE` mode, you may annotate
 an individual `@Nested` test class with
diff --git a/framework-docs/modules/ROOT/pages/testing/testcontext-framework/test-execution-events.adoc b/framework-docs/modules/ROOT/pages/testing/testcontext-framework/test-execution-events.adoc
index b83c127367..922f9e2fb4 100644
--- a/framework-docs/modules/ROOT/pages/testing/testcontext-framework/test-execution-events.adoc
+++ b/framework-docs/modules/ROOT/pages/testing/testcontext-framework/test-execution-events.adoc
@@ -1,9 +1,9 @@
 [[testcontext-test-execution-events]]
 = Test Execution Events
 
-The `EventPublishingTestExecutionListener` introduced in Spring Framework 5.2 offers an
-alternative approach to implementing a custom `TestExecutionListener`. Components in the
-test's `ApplicationContext` can listen to the following events published by the
+The `EventPublishingTestExecutionListener` offers an alternative approach to implementing
+a custom `TestExecutionListener`. Components in the test's `ApplicationContext` can
+listen to the following events published by the
 `EventPublishingTestExecutionListener`, each of which corresponds to a method in the
 `TestExecutionListener` API.