"If you look at the Spring record of backwards compatibility, it’s astonishingly good.
"One thing I keep meaning to do is download the old Spring One Sample Apps and try to run them on the new version; and I’ll pretty much guarantee you that every single one will work.
"I think we’ve done astonishingly well with backwards compatibility, not merely in respect to Spring itself, but also in respect to different environments. For example, if you go and write an EE 6 app, you can run it in one, possibly two servers. If you write a Spring app, you can go and run it on WebSphere 6, you can run it anywhere; and I think that has materially helped people in terms of both the upgrade of the framework, and the server to which they may be deploying.
Generally, with deprecation, we do take a more proactive view than Java as a whole. It seems that the view of Java is that deprecation means nothing, whereas our view of deprecation is that if you deprecate something, you take it out in the next major release.
"Deprecation actually says something. It says ‘this is going to disappear in probably 18-month’s-time.’
"But generally, where we have deprecated, we have deprecated SPI style methods that do not affect the majority of code. Bear in mind that the majority of code doesn’t need to call the core of Spring very much. Spring is based around fairly transparent services, which is why you can take business objects that work in Spring One, and you can run them in Spring 3.1.
"I think it’s very important that as you add some stuff you’ve got to remove some stuff, otherwise it just becomes confusing. You really need to help people understand best practices. If something is deprecated, it’s probably because we found a better way to do it."
-Rod Johnson on SpringSource, method deprecation, and backwards compatibility.
How to set up backwards compatibility tests for modern, complex apps