To answer, let me first turn the question around on the need to upgrade.
If you never upgrade, over time you are stuck on an outdated version and will find bugs in your system that results from bugs in the library that have been fixed in later versions.
Assuming that you are continuing to develop your system, and the relevant library is of any size of complexity, sooner or later it will be worth upgrading. I.e. the cost of retesting justifies the benefit of the remaining on the latest version.
So, you may not need to upgrade if these assumptions fail.
- You are not actively your application.
- The library has minimal changes, perhaps only changes to specific problems that you know are not relevant to you.
It's more complex that this, as (2) is a moving target. With each library version that comes out, the accumulated change increases and hence the likely value (as well as risk and testing requirements).
Note that if you delay upgrade a long time "because so far none of the fixes matter to me", then when you do upgrade you may find it much harder due to accumulated impact.
Further, you may have multiple third party libraries that may require upgrade and retest from time to time. One approach is to review and consider upgrade of all third party libraries once per year (or whatever period), and execute the upgrade within a single project, allowing a single full system regression test. This might include upgrade to compiler or operating as well.
Finally, any risk in an upgrade will be inverse to the amount of automated testing in place. If you have very little (relevant to the library) and need to do a lot of manual testing you need more benefit to justify the upgrade cost.
So for example, upgrading a user interface library which requires extensive GUI retest is different to upgrading an XML lib which reads in a few files amenable an automated test.