0.6.0 release candidate 1

Significant new features

Support for mixed-language programming by supporting multiple (de)serializers for a single topic in a single process. This way, a program that consists of, say, C and C++ can use a different representation of the data in C than in C++. Before, all readers/writers in the process would be forced to use the same representation (or perform an additional copy). Currently C is still the only natively supported language, but one can use an evolving-but-reasonable-stable interface to implement different mappings.

Improved QoS support: full support for deadline, lifespan and liveliness. The first is for generating notifications when a configured instance update rate is not achieved, the second for automatically removing stale samples, the third for different modes of monitoring the liveliness of peers.

Improved scalability in matching readers and writers. Before it used to try matching a new local or remote reader or writer with all known local & remote entities, now only with the right group with the correct topic name.

Improved tracing: discovery data is now printed properly and user samples have more type information allowing floating-point and signed numbers to be traced in a more readable form.

Extension of platform support

• Known to work on FreeBSD, CheriBSD
• Known to work with the musl C library

Windows-specific changes

• Fixes multicasts to addresses also used by non-Cyclone processes (caused by accidentally linking with an old sockets library)
• Correct handling of non-English network interface names

Compatibility notes

There no compatibility issues with, except for one small change in the creation of "topic" entities. The "create topic" and "find topic" operations now create a new entity (thus with a unique handle), matching the DDS specification. Previously these would simply return the existing one when the topic was already known. This only substantially affects programs that:

• call these operations in a loop for a single topic (this will now leak memory);
• deliberately delete a topic after calling these operations multiple times for that topic with the aim of recreating it with a different QoS (because the topic now remains in existence, this now results in a subsequent dds_create_topic failing with an incompatible QoS error);
• call these operations multiple times for a single topic and compare topic handles of readers/writers (because the handles are now no longer guaranteed to be the same).
  Simply calling these functions a few times at start-up without depending on the topic handle being the same will simply mean a slight increase in memory usage. Once one deletes the participant, all these topics will be deleted and no memory will be leaked.

The three cases above are deemed sufficiently rare that the change in behaviour is warranted within a single major version. Indeed, one could even argue this is merely a bug fix.