We advise upgrading OpenSplice DDS when a new release becomes available. New releases contain bug fixes and changes as well as additional operating system support. This page gives guidance for upgrading OpenSplice.

Switching to the next OpenSplice DDS version

The OpenSplice DDS versioning policy reflects the severity of the changes between releases. Changes can have an impact in two areas:

portability
interoperability

Portability changes are usually due to changes in the existing APIs while interoperability aspects are typically due to changes in the DDS wire-protocols. As the related OMG specifications (DDS rev 1.2, DDSI rev2.1) are becoming more mature and with the adoption of extensible wire protocols interoperability can be increasingly guaranteed as explained below.

Understanding the version number

The OpenSplice DDS version consists of 3 digits: major, minor and maintenance (in that order). Additionally, there may be patch releases made available for customers with appropriate support contracts. For example OpenSplice 6.8.0 means major release version 6, minor release version 8 and maintenance release version 0. There may also be a p1 number at the end if it is a customer patch release.

The impact of upgrading to a major, minor or maintenance release updates on installation, coding and coding/generation is shown below.

Upgrading to a new major release

A Major release typically indicates some major functional additions to the product and/or high-impact changes to existing functionality. These changes could be syntactic and/or behavioural changes to existing DDS APIs. A Major release is always accompanied by a migration guide detailing the DDS API changes. If there are changes in the behaviour of OpenSplice the migration guide will provide recommendations on how to mimic the old behaviour or migrate to the new behaviour.

We guarantee wire-protocol interoperability within a major release (for all the minor releases). Interoperability between major versions is a design goal rather than a guarantee. This is because there can be evolutions in the wire protocol specification (s) and/or its implementation that require upgrade to the same major release. If a new release is NOT backwardly compatible with the previous one the release notes will indicate this.

Steps for upgrading to a new major release

The actions to take upon changing to a new major release are:

Installing/Interoperability: If the new major release is not compatible with the previous major release then the new major release should be installed on all computing nodes of the distributed system. Any old persistent stores relating to data from the old major release may need to be deleted. This information can be found in the release notes.
Coding: If the APIs have been changed syntactically or behaviourally you may need to adapt your Application code. Please check the migration guide to see if this applies to your application
Compiling: Applications that are to be ran on the new major release shall be re-generated using the related OpenSplice DDS IDL preprocessor followed by compilation of the generated code with a compile-suite (-version) suitable for the new major release of OpenSplice (as indicated in the release-notes)
License: Upgrading to a new major release usually requires a new license key. Please contact [email protected] for more information.

Upgrading to a new minor release

A minor release typically introduces new functionality APIs and/or provides bug-fixes (that might include code-generation).

Steps for upgrading to a new minor release

Upgrading to a new minor version implies the following for existing nodes and applications

Installing/Interoperability: We guarantee interoperability between minor release (of the same major release). Existing nodes (with existing applications) do not need to be upgraded.
Compiling: Applications that are to be ran on the new minor release shall be re-generated using the related OpenSplice DDS IDL preprocessor followed by compilation of the generated code

Upgrading to a new Maintenance Release

A maintenance release contains execution level bug fixes only and is made available on standard platforms. It is compatible with any previous version of OpenSplice DDS with the same major and minor version number.

Steps for upgrading to a new maintenance release

Portability (of existing applications) and interoperability (with existing nodes) is guaranteed implying that no recompilation is required, and that the new maintenance release can be freely installed on any node in the distributed system.

WARNING: re-compilation may be required for maintenance version upgrades for applications built on top of the ISOC++ (v2) API’s.

This is due to the nature of the language in combination with how the API standard works. The OMG-delivered header files that must be used in order to be compliant, contain many so-called templates. These templates have to be implemented in header files due to the nature of the C++ language. The downside of the ‘template approach’ is that any change in the template code of our product, leads to a requirement for re-compilation of any applications built on top of them. This means if a change was made in one or more of the templates in the API, your applications will have to be recompiled.

Upgrading to a Patch Release

A patch release contains specific bugfixes for specific platforms only and is compatible and interoperable with any previous version of OpenSplice DDS with the same major, minor and maintenance version number. A patch release is identified by a “pxx” version where xx is an incremental patch number after the maintenance release digit

Steps for upgrading to a new patch release

Portability (of existing applications) and interoperability (with existing nodes) is guaranteed implying that no recompilation is required and that the new maintenance release can be selectively installed on relevant nodes (that require the patch) in the system.

WARNING: re-compilation may be required for patch version upgrades for applications built on top of the ISOC++ (v2) API’s.