SEC-2123: Upgrade dependencies of spring-security-web to match it's own version #2349

Closed
spring-issuemaster opened this Issue Jan 20, 2013 · 5 comments

2 participants

@spring-issuemaster

Eugen Paraschiv (Migrated from SEC-2123) said:

Currently, spring-security-web 3.1.3.RELEASE still defines dependencies to 3.0.7.RELEASE versions of some/most Spring artifacts (spring-jdbc, spring-aop).

Even though Spring and Spring Security are not strictly on the same release cycle, it would still help if the minor releases (described here: https://github.com/SpringSource/spring-build-gradle/wiki/Spring-project-versioning) would be coordinated.
This would mean that the latest in Spring Security 3.1.x would use the latest in Spring 3.1.x. Otherwise, with Maven shortest path resolution mechanism, making sure that all dependencies match is not at all easy.

@spring-issuemaster

Rob Winch said:

Spring Security will never be in lock-step releases with Spring. If you need to use a different version of Spring, specify the versions explicitly.

@spring-issuemaster

Eugen Paraschiv said:

Right, so would it make sense then to open up specific JIRA issues tracking upgrading specific dependencies - for example, upgrading the spring-jdbc dependency (which is now 3.0.7.RELEASE) to something newer? Or is there a specific reason these need to stay at 3.0.7?
Thanks.
Eugen.

@spring-issuemaster

Rob Winch said:

Spring Security 3.1 follows a minimum of the Spring 3.0.x line and will stay consistent with that. Spring 3.0.7 is the latest release in that line, so there is not going to be an update to the dependencies until 3.0.8 is released. Spring Security 3.2 will update and follow the Spring 3.2 releases. Before a release is done the dependencies are checked to see that the latest of the release it is following is added as a dependency. So on short, there is no need for a JIRA (and certainly not a bug) since 3.0.7 is the latests 3.0.x

@spring-issuemaster

Eugen Paraschiv said:

Not a bug indeed (must have been default when I created it) - my thinking was that, if Spring Security 3.2 will use the Spring 3.2 releases, than it would also make sense that Spring Security 3.1 would follow Spring 3.1 releases, which is why I suggested the improvement. Since Spring Security isn't on the same release schedule as Spring itself, 3.0.x also makes sense.
Thanks.

@spring-issuemaster

Rob Winch said:

Spring Security 3.1.x follows Spring 3.0.x because Spring Security 3.1.x was done before Spring 3.1.x. It remains that way to ensure users do not need to update Spring. I hope to establish a bit closer alignment between the versions with the coming releases.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment