Stop referring to old Spring versions in the reference manual

Author: sbrannen

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