views:

48

answers:

5

I work with a lot of open source libraries in my daily tasks (java FYI). By the time a project comes close to maturing, many of the libraries have released newer versions. Do people generally upgrade just to upgrade, or wait until you see a specific bug? Often the release notes say things like "improved performance and memory management", so I'm not sure if it's worth it to potentially break something. But on the other hand most libraries strive and claim to not break anything when releasing new versions.

What is your stance on this? I'll admit, I am kind of addicted to upgrading the libraries. Often times it really does help with performance and making things easier.

+2  A: 

I keep what works until there is a reason to upgrade.

Philluminati
+3  A: 

The rule for us is to stay up to date before integration testing but to permit no changes to any library once we're past this point. Of course, if integration testing reveals flaws that are due to an issue with a library that has been fixed, then we'd go back and update. Fortunately, I cannot remember a situation where that has happened.

Update: I understand Philuminati's point about not upgrading until you have a reason. However, I think of it this way: I continuously pursue improvements in my own code and I use libraries built by people that I believe think the same way. Would I fail to use my own improved code? Well, no. So why would I fail to use the code that others have improved?

Mark Brittingham
If you had a reason to "improve" your own code then great....if you didn't then you're making unnecessary changes to your code base.Never make a change without a specific reason and put that reason in the commit on its own.leave the next improvement to the next commit.Each change should be isolated.
Philluminati
A: 

If the information pertaining the old version appears on secunia or securityfocus...

Otherwise - if new functionality is needed (better performance is also a 'functionality').

Anonymous
A: 

It depends a lot on your deployments. If you are supporting multiple platforms then the very latest libraries may not be available on all at any given moment. I've been frustrated by trying to install something that requires the very latest version of some lib, and it's not available as a package yet.

If you deploy to customers you want to develop against libraries that are stable and widely available.

dwc
+1  A: 

I'm with the lazy crowd - I can't remember ever formulating a different strategy than "upgrade when there is a reason to" - but now that I consider the question, there is something to be said about proactive upgrades.

Upgrading does make it easier for you to report a bug in the lib, should you find one. If you find a bug and have not upgraded, it's the first thing you're going to have to do before you get any help or support. You might as well do that proactively.

Especially if you have a good test suite, upgrading proactively will flush out problems early, and that is always a smart move.

Morendil