One of my projects just changed the version number of a supporting third-party library. Specifically, we changed a J2EE app from JPA 1.x to JPA 2.0. Our CI system has had this change for a week and the tests are passing.

In general, how can I do an effective code review and QA check when another developer changes the version of a third-party library?

I have already done the following:

  • reviewed the changelogs for the library, watching for things that would affect my application
  • checked the dependency declarations (Maven POMs) for mistakes
  • searched our ticketing system for prior attempts or upgrades of the same libraries, did we try this before and fail or find a blocker
  • 1
    Sharing your research helps everyone. Tell us what you've tried and why it didn’t meet your needs. This demonstrates that you’ve taken the time to try to help yourself, it saves us from reiterating obvious answers, and most of all it helps you get a more specific and relevant answer. Also see How to Ask
    – gnat
    Commented Apr 11, 2014 at 15:41

1 Answer 1


If the library follows the Open/closed principle, then you just need to review the release notes for any significant changes. If not, there should be a migration guide to help you upgrade. The release notes usually list significant new features as well as any deprecated features. Plan your strategy on dealing with the deprecated features. You may also want to plan modifications to take advantage of new features.

On occasion, I have seen libraries which try to follow the Open/closed principle violate it to add new functionality. This has been documented with a discussion on the reasons why they broke the principle, and notes on how to adapt.

Review the changelog for changes significant to your project. If you depend on or have worked around a bug in the library's behavior, review the changelog to see if the bug has been addressed. Review the changelog for subsequent releases to see if they identify any bugs that apply to your project.

You may want to review Javadoc, if available, of both versions to see if there are any significant changes. You may want to limit the comparison to the features you use. Any differences should already have been addressed by the items above.

Run you test suites against the new code. Don't panic if you get failures. These may be newly correct behavior. Assess each failure, and determine how to proceed.

Review any code changes implemented in the change that implemented the new library. These should only be the changes, if any, required to change version. The prior steps should have identified the types of changes you see.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.