Question

I work on a project that uses multiple open source Java libraries. When upgrades to those libraries come out, we tend to follow a conservative strategy:

1. if it ain’t broke, don’t fix it
2. if it doesn’t have new features we want, ignore it

We follow this strategy because we usually don’t have time to put in the new library and thoroughly test the overall application. (Like many software development teams we’re always behind schedule on features we promised months ago.)

But, I sometimes wonder if this strategy is wise given that some performance improvements and a large number of bug fixes usually come with library upgrades. (i.e. ‘Who knows, maybe things will work better in a way we don’t foresee…’)

What criteria do you use when you make these types of decisions in your project?

Answer 1

I’ve learned enough lessons to do the following:

1. Check the library’s change list. What did they fix? Do I care? If there isn’t a change list, then the library isn’t used in my project.
2. What are people posting about on the Library’s forum? Are there a rash of posts starting shortly after release pointing out obvious problems?
3. Along the same vein as number 2, don’t upgrade immediately. EVERYONE has a bad release. I don’t intend to be the first to get bit with that little bug. (anymore that is). This doesn’t mean wait 6 months either. Within the first month of release you should know the downsides.
4. When I decide to go ahead with an upgrade; test, test test. Here automated testing is extremely important.

EDIT: I wanted to add one more item which is at least as important, and maybe more so than the others.

• What breaking changes were introduced in this release? In other words, is the library going off in a different direction? If the library is deprecating or replacing functionality you will want to stay on top of that.