Stop referring to old Spring versions in the reference manual

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