Now I have made a small change in an object's function which Y holds.
What need to be done depends on the specific change you made. For those types of situation, we can discriminate between two types of changes: ABI-breaking changes, and ABI-compatible changes.
ABI (Application binary interface) is the interface of a compiled object at the binary level. Similarly of the way C++ functions have an API (e.g. the function's signatures are part of an API), compiled machine language have an ABI which depends on the API and the calling convention, amongst other things.
Knowing what changes are ABI-breaking and which are not can sometime be a difficult task. But as a rule of thumb:
- if you did not change Y's API, Y's ABI is unchanged;
- if you did change Y's API, Y's ABI is changed.
Now, if you broke Y
's ABI, you should release a new version of it (let's call it Y-2
). X
won't be compatible with Y-2
and would require to be upgraded (optionally) and recompiled (mandatory) and released as a new version (let's call it X-2
). X
and Y-2
are not ABI compatible. X-2
and Y
are not ABI compatible.
If Y
's ABI is untouched, you can safely distribute your new version of Y
(let's call it Y-1.1
) which will replace Y
on target computers and link with the original X
.
From a comment, it appears that:
The change I have done is just deleting a leaked object and made it to NULL.
This is neither an API not ABI breaking change. You can safely distribute Y-1.1
only.