0

Similar to Can I use new spring 3.2 with older spring-security 3.0...

Why does Spring Security not follow the main Spring framework's versioning? I know how Maven dependency management works and that it doesn't strictly have to share the exact same version number, but it's very irritating to have to explicitly exclude the transitive dependencies it declares on old Spring core versions.

Consider the impact of this on a hypotyhetical Spring/Maven newbie: it presents an immediate unshaven haven of Maven raven. Multiple versions of Spring libraries saturating your lib folder, non-deterministic cross-version anomalies, etc.

Quo vadis?

Community
  • 1
  • 1
Cornel Masson
  • 1,352
  • 2
  • 17
  • 33

1 Answers1

2

They are different projects. It's the same with Spring Integration, Batch... Imagine that you have to release Spring Security for some small bug. If you keep the versions in sync, than you need to rise the core version just for this...

Evgeni Dimitrov
  • 21,976
  • 33
  • 120
  • 145
  • Yep, different projects understood. However, can Spring subprojects not declare their dependencies in a way that will accept _newer_ versions if the explicit version is not available? I seem to remember this being possible using _version ranges_? Is it because it declares its dependencies on versions that don't follow the strict semver {major}.{minor}.{incrmnt} pattern, e.g. '3.2.6.RELEASE' instead of just '3.2.6'. AFAIK, if the version number contains non-strict tokens (like '.RELEASE'), Maven reverts to using absolute version matching instead of trying to match compatible ranges? – Cornel Masson Feb 11 '14 at 08:33
  • 1
    I would never do this since there is no guarantee that newer releases will always be backwards compatible. In fact, every major Spring version and many intermediate versions have breaking changes. This is required to pay back technical debt. I would always include those specific versions that I know my application compiles with and has been tested against. – manish Feb 12 '14 at 17:04