Remove outdated Spring version mentions

Close gh-35696

framework-docs/modules/ROOT/pages/core/aop-api/targetsource.adoc

@@ -87,14 +87,12 @@ A crucial difference between Spring pooling and SLSB pooling is that Spring pool
 be applied to any POJO. As with Spring in general, this service can be applied in a
 non-invasive way.
 
-Spring provides support for Commons Pool 2.2, which provides a
+Spring provides support for Commons Pool 2, which provides a
 fairly efficient pooling implementation. You need the `commons-pool` Jar on your
 application's classpath to use this feature. You can also subclass
 `org.springframework.aop.target.AbstractPoolingTargetSource` to support any other
 pooling API.
 
-NOTE: Commons Pool 1.5+ is also supported but is deprecated as of Spring Framework 4.2.
-
 The following listing shows an example configuration:
 
 [source,xml,indent=0,subs="verbatim,quotes"]

framework-docs/modules/ROOT/pages/core/beans/classpath-scanning.adoc

@@ -1045,10 +1045,10 @@ methods anywhere. However, regular `@Bean` methods in `@Configuration` classes n
 to be overridable -- that is, they must not be declared as `private` or `final`.
 
 `@Bean` methods are also discovered on base classes of a given component or
-configuration class, as well as on Java 8 default methods declared in interfaces
+configuration class, as well as on Java default methods declared in interfaces
 implemented by the component or configuration class. This allows for a lot of
 flexibility in composing complex configuration arrangements, with even multiple
-inheritance being possible through Java 8 default methods as of Spring 4.2.
+inheritance being possible through Java default methods.
 
 Finally, a single class may hold multiple `@Bean` methods for the same
 bean, as an arrangement of multiple factory methods to use depending on available

framework-docs/modules/ROOT/pages/core/beans/definition.adoc

@@ -99,7 +99,7 @@ the `@Bean` factory method in favor of any pre-declared constructor on the bean
 ****
 
 NOTE: We acknowledge that overriding beans in test scenarios is convenient, and there is
-explicit support for this as of Spring Framework 6.2. Please refer to
+explicit support for this. Please refer to
 xref:testing/testcontext-framework/bean-overriding.adoc[this section] for more details.
 
 

framework-docs/modules/ROOT/pages/core/beans/java/composing-configuration-classes.adoc

@@ -327,9 +327,8 @@ Kotlin::
 ----
 ======
 
-TIP: Constructor injection in `@Configuration` classes is only supported as of Spring
-Framework 4.3. Note also that there is no need to specify `@Autowired` if the target
-bean defines only one constructor.
+TIP: Note that there is no need to specify `@Autowired` if the target bean defines
+only one constructor.
 
 [discrete]
 [[beans-java-injecting-imported-beans-fq]]

framework-docs/modules/ROOT/pages/languages/dynamic.adoc

@@ -9,8 +9,7 @@ objects.
 
 Spring's scripting support primarily targets Groovy and BeanShell. Beyond those
 specifically supported languages, the JSR-223 scripting mechanism is supported
-for integration with any JSR-223 capable language provider (as of Spring 4.2),
-for example, JRuby.
+for integration with any JSR-223 capable language provider, for example, JRuby.
 
 You can find fully working examples of where this dynamic language support can be
 immediately useful in xref:languages/dynamic.adoc#dynamic-language-scenarios[Scenarios].

framework-docs/modules/ROOT/pages/testing/testcontext-framework/tx.adoc

@@ -309,7 +309,7 @@ before-transaction method or after-transaction method runs at the appropriate ti
 Generally speaking, `@BeforeTransaction` and `@AfterTransaction` methods must not accept
 any arguments.
 
-However, as of Spring Framework 6.1, for tests using the 
+However, for tests using the
 xref:testing/testcontext-framework/support-classes.adoc#testcontext-junit-jupiter-extension[`SpringExtension`]
 with JUnit Jupiter, `@BeforeTransaction` and `@AfterTransaction` methods may optionally
 accept arguments which will be resolved by any registered JUnit `ParameterResolver`

framework-docs/modules/ROOT/pages/web/webmvc/mvc-servlet/multipart.adoc

@@ -6,8 +6,6 @@
 `MultipartResolver` from the `org.springframework.web.multipart` package is a strategy
 for parsing multipart requests including file uploads. There is a container-based
 `StandardServletMultipartResolver` implementation for Servlet multipart request parsing.
-Note that the outdated `CommonsMultipartResolver` based on Apache Commons FileUpload is
-not available anymore, as of Spring Framework 6.0 with its new Servlet 5.0+ baseline.
 
 To enable multipart handling, you need to declare a `MultipartResolver` bean in your
 `DispatcherServlet` Spring configuration with a name of `multipartResolver`.