Stop referring to old Spring versions in the reference manual

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

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]
 ======

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.
 

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

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.
 ====
 

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].

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"]

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.
 

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`

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

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]
 ======

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.

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`

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

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

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.