Vortex OpenSplice - documentation index

##### Vortex OpenSplice

- Introduction
- User Guides
- Changes
- Supported Platforms
- Known Issues
- DDSI Release Notes
- Rebuilding the APIs
- Upgrading OpenSplice
- Examples
- Third party licenses
- License

## Switching to the next OpenSplice DDS version

OpenSplice DDS uses a versioning policy, which reflects the severity i.e. impact of the changes applied. Impact of any change can be on portability as well as on interoperability. Portability aspects are typically driven by changes in (existing) APIs whereas interoperability aspects are typically driven by changes in DDS (wire-)protocols. With the related OMG specifications (DDS rev 1.2, DDSI rev2.1) becoming more mature as well as the adoption of extensible wire-protocols, interoperability can be increasingly guaranteed as explained below.

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. The impact of major/minor/ maintenance release updates on installation, coding and coding/generation is as follows:

- Major: 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 behavioral changes on existing DDS APIs. A Major release is always accompanied by a migration guide detailing the DDS API changes and in case of behavioral changes, it contains recommendations (if possible) on how to either mimic the old behavior or migrate towards the new behavior.
  Whereas wire-protocol interoperability is now guaranteed within a major release (i.e. for all minor releases), interoperability between major versions is a design-goal rather than a guarantee as there can be evolutions in the wire-protocol specification(s) and/or its implementation that would demand upgrading to the same major release. The Release-notes of each major release will clearly indicate when a new major release is NOT backwards-compatible with the previous one.
  The actions to take upon changing to a new major release are:
  - Installing/Interoperability: In case of indicated non-compatibility with the previous major release, the new major release must be installed on all computing nodes of the distributed system and old persistent-stores (that relate to data of the old major release) must potentially be deleted (if release notes of the new major release so indicate)
  - Coding: Application code has to be adapted if and only if an application uses APIs that have either been changed syntactically or changed behaviorally.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)
- Minor: A minor release typically introduces new functionality APIs and/or provides bug-fixes (that might include code-generation). Changing to a new minor release therefore implies the following for existing nodes and applications:
  - Installing/Interoperability: existing nodes (with existing applications) don't require to be upgraded to the latest minor release as interoperability between minor-releases (of the same major-release) is guaranteed
  - 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
- Maintenance: A maintenance release contains execution-level bugfixes 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. 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 down-side 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.
- Patch: 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. 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. 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 down-side 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.