My company has several products on the market, developed in multiple offices in Europe and the US, which use the same common library. This common library wraps up a lot of industry-specific details, as well as adds some enhanced user controls, extension methods, math bits, etc.
Problems arise when QA comes back with a bug or the product owner for one of the products wants a change, and that bug or change requires changes to the code in the shared library. Because it is a change to a library used by all of our products, the change can have far reaching effects. The defect / bug report / change request is typically placed in the product backlog for the "original" product - that is, the product being tested by QA or owned by the PO requesting the change. This means that there is very little visibility in the other products for these changes, and things may break (very obviously with compile-time errors or more subtly with different run-time behavior) when the library is updated in those other products. QA for the other products may see the changes as regression failures.
The library is fairly mature at this point, so most of the changes being made are the result of bugfixes. Changes are submitted via a pull request, where a representative from each of the regional offices can review it (though only 1 needs to approve it); known high-impact changes are typically communicated over email, but may be forgotten by the time development resumes on a given project.
How can I manage a library like this, to ensure a good visibility among QA product owner, and the Developers?