1. Important: How to Use this Guide
1.1. Upgrade Path
This Migration Guide describes how to upgrade to any of the RTI® Connext® 6 and 7 releases from release 5.3.1 or later.
See the upgrade considerations in this guide for each applicable release. For example, if you are upgrading from 6.1.0 to 7.2.0, see all of the following sections: Upgrading from 6.0.1 to 6.1.0, Upgrading from 6.1.0 to 6.1.1/6.1.2, and Upgrading from 6.1.1/6.1.2 to 7.2.0. Together, these sections provide important upgrade considerations that apply when upgrading from your current to your new release.
Whether you will keep some of your legacy Connext systems or migrate entirely to a Connext 6 or 7 release, read this guide to see what settings or other changes you may need to make before you upgrade all or part of your system. The full set of changes for your release is described in the What’s New and Core Libraries Release Notes documents for your release:
This guide describes only those changes that may break old behavior.
1.2. Upgrade Steps
Whenever upgrading to a new, major release, you must regenerate the type-specific code that was generated from your IDL, XML, or XSD definitions with the new version of rtiddsgen, then recompile and re-link your applications with the new versions of the Connext libraries. The basic steps are as follows:
Make the changes required for your system, based on the compatibility issues described in this guide:
See the “Product-Specific Compatibility” section for your release, for issues that affect your products.
See the “General Compatibility” section for your release. This section is particularly important if your release will coexist with older releases.
See Regressions for any issues that may apply to you.
Regenerate code as described in Section 1.3.1.
Recompile your source as described in Section 1.3.2.
If you had early access to a pre-release version of Connext, delete
(or move or rename) the
rti_workspace/7.1.0) before installing.
1.3. Regenerating and Recompiling
1.3.1. Generated code compatibility
For Connext applications defining types in IDL, XML, or XSD, moving between any two releases in this guide requires code regeneration and recompilation.
You will need to regenerate the code for your application types using the RTI Code Generator shipped with your release. The regeneration process is simple; you only need to run the new version of Code Generator using the original input IDL file. For example:
rtiddsgen -language C++11 -update typefiles your_previous_release_IDL.idl
You should see a message that says you are running rtiddsgen version 3.0.0 if you are upgrading to 6.0.0, rtiddsgen version 3.0.1 if you are upgrading to 6.0.1, rtiddsgen version 3.1.0 if you are upgrading to 6.1.0, rtiddsgen version 3.1.1 if you are upgrading to 6.1.1, rtiddsgen version 3.1.2 if you are upgrading to 6.1.2, or rtiddsgen version 4.1.0 if you are upgrading to 7.1.0.
This process will regenerate the header and source files, which can then be compiled along with the rest of your application.
1.3.2. Application Binary Interface
RTI Connext does not provide Application Binary Interface (ABI) compatibility with previous versions of Connext. Therefore, an application compiled using a previous version of Connext must be recompiled when moving to a new Connext 6.x.x or 7.x.x version.
The Connext core primarily consists of libraries and a set of header files. In most cases, upgrading simply requires you to recompile your source using the new header files and link your application with the new libraries. In some cases, minor modifications to your application code might be required; any such changes are noted in this Migration Guide.
After you make modifications to your application code, recompile your source using the new header files and link the new libraries.