Vortex OpenSplice 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 Vortex OpenSplice 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 Vortex OpenSplice IDL preprocessor
followed by compilation
of the generated code with a compile-suite (-version) suitable for
the new major release of Vortex 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 minor release
shall be re-generated using the related Vortex OpenSplice 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 Vortex OpenSplice 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 Vortex
OpenSplice 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.
