Backwards compatibility?

[crazydef]

Hi,

We're using libsrt version 1.4.4 in various releases of our application. I'm just wondering whether there are any possible or known backwards compatibility issues with a newer version of the library connecting to and talking with an older version?

I.e., if I upgrade to the latest version of libsrt, will everything Just Work when connecting to an older version of our application using the older version of libsrt? Or is this dependent on which features we have enabled? Or is 1.4 completely incompatible with version 1.5, for example?

And has the API changed significantly (or at all) between 1.4.4 and the latest release?

[ethouris]

Depends on which level, or in other words, which exactly parts of the solution stay with old version and which are upgraded. There are several separate parts here:

1. The interface part (header files)
2. The shared library
3. The other peer

(1 and 2 can be taken together in case of using static library)

As for the protocol (that is, the last aspect) the compatibility is kept so far up to version 1.2.0 (the first version published in Github), although we plan to abandon the backward compatibility on the protocol level with older versions than 1.3.0. Some new features added in new versions (like Bonding or FEC) will not work if the peer doesn't support them. But all features provided in the oldest supported version will continue to work, regardless of the changes in the newer versions - all later versions support earlier features.

As for the ABI (aspect 2), we keep the rule of having the line with particular major.minor version to be ABI-compatible with all previous ones in the same line. Changes in the API may be in the form of new things, but no other changes are possible within the versions of a single minor version line.

[crazydef]

Thanks.

For parts 1 and 2, everything is shipped as a single package as far as our application is concerned. We don't upgrade individual parts, or rely on shared libraries already present on the machine. So in that regard, I'm merely interested in knowing how much work will be potentially involved from a recompile perspective.

[ethouris]

You may find sometimes things that are declared deprecated, and if so, recommended changes may be needed, that's about all. Deprecation usually concerns functions that either no longer work the old way, or contain some outdated approach, although they still work.

For example, srt_socket shall no lonber be used, in favor of srt_create_socket. The old function still works, just all arguments are ignored (and it works just like srt_create_socket, which has no arguments).

[JohnMAllay011]

Upgrading from liberty 1.4.4 to a newer version should generally maintain backward compatibility, but thorough testing is recommended to ensure compatibility with older versions of your application. Review release notes for API changes and conduct comprehensive testing before deploying the new version in production.