You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
So far, Spring Data modules have required the latest Spring 3.2.x version as dependency and the modules integrate with new features available in Spring 4 in a lenient way.
However, an upgrade to Spring 4 would allow us to remove a few of these lenient checks for the Spring 4 presence and make use of new features like the @Conditional annotation, better JDK 8 integration etc. With Spring 4.1 to be released by the time we're going to GA with the Evans release train, we'd still adhere to the "compatibility with the last but one Spring version" mantra.
Moving to Spring 4 as new baseline would also mean that the service releases for the current Spring Data Dijkstra release trains are probably maintained for a longer time than we used to do for Babbage or Codd. Still, all major new features would go into a Spring 4 based Evans.
In case you have objections to this move, feel free to elaborate on them. A plain -1 is not a convincing argument. Wouldn't mind to get supporting comments as well.
The text was updated successfully, but these errors were encountered:
+1. I'm (mostly) always in favour of moving ahead with newer codebases and working with better implementations. Spring 4 would be a marvelous baseline and would encourage more people to migrate upwards thus gaining the advantages that this brings.
Spring 4 would be a marvelous baseline and would encourage more people to migrate upwards thus gaining the advantages that this brings.
Thanks, David. A key idea behind the upgrade is to create these incentives. Also, we think that if people are able to upgrade to a latest version of Spring Data, they should be also upgrade to a Spring 4 version. I know, there might be political and organization issues involved. That's why - assuming we eventually follow the suggestion here - we're going to extend the maintenance period for the current Dijkstra release to give users more time to upgrade.
+1 I'm also almost always in favor of using the newer implementations! My experience with upgrading some of our current systems to Spring 4 was pretty painless, so I don't think that technical issues are really a matter in such an upgrade.
Upgraded to Spring 4.0.5.RELEASE as baseline for Spring Data builds. Removed spring32-next profile as well as the spring4 one. Added a dedicated spring41-next profile to be able to build against Spring 4.1 snapshots.
So far, Spring Data modules have required the latest Spring 3.2.x version as dependency and the modules integrate with new features available in Spring 4 in a lenient way.
However, an upgrade to Spring 4 would allow us to remove a few of these lenient checks for the Spring 4 presence and make use of new features like the
@Conditional
annotation, better JDK 8 integration etc. With Spring 4.1 to be released by the time we're going to GA with the Evans release train, we'd still adhere to the "compatibility with the last but one Spring version" mantra.Moving to Spring 4 as new baseline would also mean that the service releases for the current Spring Data Dijkstra release trains are probably maintained for a longer time than we used to do for Babbage or Codd. Still, all major new features would go into a Spring 4 based Evans.
In case you have objections to this move, feel free to elaborate on them. A plain -1 is not a convincing argument. Wouldn't mind to get supporting comments as well.
The text was updated successfully, but these errors were encountered: