The creation of a new externally versioned shared object is a major change. Be sure you understand the complete dependencies of any processes that use a member of a family of externally versioned shared objects.
For example, an application might have a dependency on libfoo.so.1 and an externally delivered object libISV.so.1. This latter object might also have a dependency on libfoo.so.1. The application might be redesigned to use the new interfaces in libfoo.so.2. However, the application might not change the use of the external object libISV.so.1. Depending on the scope of visibility of the implementations of libfoo.so that get loaded at runtime, both major versions of the file can be brought into the running process. The only reason to change the version of libfoo.so is to mark an incompatible change. Therefore, having both versions of the object within a process can lead to incorrect symbol binding and hence undesirable interactions.
The creation of an incompatible interface change should be avoided. Only if you have full control over the interface definition, and all of the objects that reference this definition, should an incompatible change be considered.