Like many others, I'm looking at upgrading from Spring 5.3.13 to 5.3.18. According to semantic versioning, that should be a patch upgrade and thus not introduce new or changed APIs or dependencies. However, the diff for build.gradle includes the following changes:
- org.jetbrains.dokka 1.5.0 -> 1.6.10
- org.apache.logging.log4j 2.14.1 -> 2.17.2
- io.smallrye.reactive:mutiny 1.1.1 -> 1.4.0
- com.google.protobuf:protobuf-java-util 3.18.0 -> 3.19.3
- com.h2database:h2 1.4.200 -> 2.1.210
- com.rometools:rome 1.16.0 -> 1.18.0
- org.xmlunit 2.8.3 -> 2.9.0
- org.assertj:assertj-core 3.21.0 -> 3.22.0
- org.mockito 4.0.0 -> 4.4.0
- net.sourceforge.htmlunit:htmlunit 2.54.0 -> 2.59.0
Many of these seem harmless or only used in testing (or utterly required like the log4j upgrade). However, some raise flags like the xmlunit or rometools upgrades because we are currently using (and shipping) the older versions.
Am I needlessly worried here?
Comment From: bclozel
Those are the versions we compile against, they are not exposed as transitive dependencies nor anywhere in the published POMs.
When upgrading those, we ensure that no code change was required on our side. If there is, we work around those changes with reflection or detection to ensure we are compatible with both versions.
In short, you should not have to worry about those upgrades on the Spring Framework side. On the other hand, you should keep an eye on the changelogs of libraries you extensively use: the Framework integration often uses a small API surface of libraries for integration but your application might use a much larger part of their API.
Comment From: nkiesel
Great! Is there a published list of transitive dependencies available?
Comment From: rodoabad
@nkiesel @bclozel does spring* use semantic versioning?
Me = Non Java developer just dropping in on this thread.
Comment From: bclozel
@rodoabad short answer is: Spring Framework does, but Spring Boot does not.
Comment From: rodoabad
Thanks, folks!