If it ain’t broken don’t fix it.

• Is there a feature you really need to use which is available in the newer version, and was missing in an older one?

• Is there an issue (bug, performance issue, etc.) which affects your project and was solved in the newer version?

If your answer is “no” for both questions, there is really no need to update, especially since updating to a new version requires you to check if it doesn’t break anything in your code, thing which may sometimes be complicated.

If your answer is “yes” for at least one of the questions, you should decide if the upgrading to the new version really worth it, keeping in mind the risk of breaking existent code and spending time checking the compatibility of your code with the newer version.

You can also inspire yourself from other large projects. For example you can see that Programmers.SE relies on JQuery 1.7.1, while on 9/14/2012, the latest version is 1.8.1.

Also see:

• “If it ain’t broken don’t fix it.” in When is SO going to upgrade their jQuery version?

• Reason to use older versions of jQuery?.

I think it makes sense to write an adapter and tests (for the interfaces essential to your application) for the dependency of the 3rd-party library to be able to better adapt to changes without fear of regression. That could convince the technical bosses to accept the upgrades with less fear. There may be a security update or other problem that forces an upgrade and it would be nice to be prepared for the change or to be able to change to another one if needed.

I hate to break this to you, but he’s right. I used to think as you do, but experience has taught me otherwise. I and some of my colleagues have had to update the frameworks of some of our web applications and while I cannot say the framework was worse, it had a lot of unforeseen consequences which was the cause of several bugs that weren’t immediately made evident to us but were discovered by our clients.

In that case, we had to update because we required a library which required a minimum version of libraries that were outdated. Of course, since we were upgrading, we updated to the most recent (stable) version of these libraries rather than get the bare minimum.

If you don’t have any need for a more updated version, you should not make your code dependent on a shifting codebase. If you don’t want to have the code on svn, then you should look into keeping only the binaries of a specific version available on svn instead. Better still, if you use maven, you can download a specific version and all its dependencies.

In my experience, the “right” way is somewhere in the middle. I’ve had the pleasure to work on both radical ends of the spectrum, and none of them were any good.

On one project we had an inexperienced lead who wanted to keep things updated for the same reason you state — to not fall behind in the long term. Aside from the problem that we had to check our own code (though with decent code coverage, it’s not that big a deal), the biggest problem is that the library is not community-tested when it’s released. The project lead got burned when clients found a bug in the framework we were using, and short of submitting patches to the framework, there was nothing we could do.

Another project I’ve had to work on is something that I remember as probably the worst nightmare of my programming career. The guys before me had decided that “updating will only introduce bugs”. So when I came along ~ mid 2010, it had Hibernate v2.1.0 and Maven v1.0.1, for both of which it was even a pain to get documentation. It was at that point that we started needing native SQL queries (it’s near impossible to do analytic functions through Hibernate without that) and native SQL was almost impossible for that version.

Now imagine upgrading a core part of a decent size enterprise project with close to no test coverage from a 2004 version of a framework to a recent one.

Does it really make sense to include a specific version of external
library in our svn and keep using it ignoring all updates?

That depends…

I have experienced both approaches, and neither is always right, nor always wrong.

Key considerations relate to how dynamic the other library is, and what risks are possible if the library updates in the future. Also, how critical your system is.

Dependencies are not ideal, and need to be managed carefully – and if you go ahead with the “fixed” approach, I recommend reviewing the development of the library periodically. It may be that the best approach is a mix of both… keep it fixed within your system, but update occasionally.

If the library is a key component, any update of that library may require wholesale re-testing of your code… which is not desirable.

The buzz words defining your argument are “continuous integration.” It is more pain in the short term, but the reason you do it is to save even more pain in the long term. Even though there may be nothing new you want from the package right now, the longer into the future you go, the more likely there will be a feature or bug fix you do want. What happens when people privately fork a project is that now to get that feature you’re pulling in years of changes all at once, and you may have no idea what some of them are. A small list of changes every week is much easier to deal with. When people talk about problems with upgrades of third party libraries, they’re talking about the huge upgrades, not from yesterday’s daily build to today’s.