Supported Version Interoperability
This page describes which components of InterSystems IRIS® data platform can be used across different release versions.
Throughout this page, “version 2024.1” refers to InterSystems IRIS version 2024.1.
For information about compatibility between InterSystems IRIS and other InterSystems software, see the InterSystems IRIS Migration Guide on the WRC distribution site under Docs.
ODBC and JDBC Interoperability
InterSystems IRIS ODBC and JDBC Clients are backward-compatible with all earlier versions of InterSystems IRIS. However, using a client with a newer version of InterSystems IRIS is not supported.
Customers are advised to upgrade their client libraries before upgrading their InterSystems IRIS server.
The following table describes the version interoperability between ODBC and JDBC clients, and servers.
Client Version | Server Version |
---|---|
2024.1 | 2018.1 through 2024.1 |
2023.2 | 2018.1 through 2023.2 |
2023.1 | 2018.1 through 2023.1 |
2022.1 | 2018.1 through 2022.1 |
2021.1 | 2018.1 through 2021.1 |
Web Gateway Interoperability
The InterSystems Web Gateway is backward-compatible with earlier versions of InterSystems IRIS. However, using an earlier version of the Web Gateway with a newer version of InterSystems IRIS is not supported.
Customers are advised to upgrade the Web Gateway before upgrading their InterSystems IRIS server.
The following table describes the version interoperability between the Web Gateway and InterSystems IRIS.
Web Gateway Version | Compatible InterSystems IRIS Versions |
---|---|
2024.1 | 2018.1 through 2024.1 |
2023.2 | 2018.1 through 2023.2 |
2023.1 | 2018.1 through 2023.1 |
2022.1 | 2018.1 through 2022.1 |
2021.1 | 2018.1 through 2021.1 |
Backup Restore Interoperability
Backups should always be restored on an InterSystems IRIS instance that is running the same, or a more recent version, than the instance that created the backup. This is because an older version of InterSystems IRIS may not be able to process newer features.
Journal Restore Interoperability (Upgrade Implications)
Journal file restores are guaranteed to be successful when restored on an InterSystems IRIS instance that is running the same, or a more recent version than the instance that created the journal file. More specifically, a journal file restore is guaranteed to be successful if the target instance uses the same version or a later version of the journal file format, relative to the journal file being used. On the other hand, journal file restores are not guaranteed to be successful when restoring to an older instance.
As a consequence, for a mirrored system, when you upgrade to a version from one version to another that uses a different journal file format, you must take care to do the upgrades in the correct order. Specifically, always upgrade backup members before upgrading the primary.
InterSystems strongly recommends always upgrading to the most recent maintenance release available for your InterSystems IRIS version to ensure feature compatibility.
Mirror Interoperability
All members of a mirror must run on the same version of InterSystems IRIS. There are two exceptions:
-
Mirror members may run on different versions for the duration of a mirror upgrade. See Upgrading a Mirror in the “Upgrading InterSystems IRIS” chapter of the Installation Guide. Once an upgraded mirror member becomes primary, you cannot allow the other failover member or any DR async members to become primary or access the application, until that member has been upgraded.
-
Async members may run on a different version than the other members of the mirror, for the following reasons:
-
DR async members may continue to run on an older version for an extended period of time, as part of a broader upgrade strategy. For example, to fall back to after upgrading the primary and backup members.
-
Reporting async members may run on a newer version to take advantage of a newer reporting features when upgrading the primary and backup members is not warranted.
-
Mirroring relies on journaling, hence the restrictions and recommendations described in the previous section also apply here.
Mirror Arbiter (ISCAgent) Interoperability
The ISCAgent serving as arbiter does not have to run the same version of InterSystems IRIS as the members of the mirror for which it is configured. We recommend that the arbiter always run a version greater than or equal to the highest version of the mirror members that connect to it. InterSystems recommends that you upgrade the arbiter when you upgrade the mirror members, so you can be sure to have the latest version of the ISCAgent.
ECP Interoperability
ECP is backward and forward compatible between InterSystems IRIS versions. This includes compiled routines and class definitions, which can be passed over ECP and run on instances that are running a different version of InterSystems IRIS. However, application code on both ends of an ECP connection must be compatible. For example, if your code performs different business logic on different ECP servers, then your overall application behavior will be unpredictable.
Customers are advised to ensure that their feature usage is compatible with all of their versions of InterSystems IRIS that are connected via ECP. For example, InterSystems IRIS 2021.2 introduced transparent stream compression. If a newer server writes stream data via ECP to an older server, the stream data won’t be readable on servers running versions that don't support transparent stream compression. Such incompatibilities can exist and are typically addressed in Maintenance Releases. InterSystems strongly recommends always upgrading your ECP configurations to the most recent maintenance release available for your InterSystems IRIS version.
Studio Interoperability
Studio is backward-compatible with earlier supported versions of InterSystems IRIS. However, using Studio with a newer version of InterSystems IRIS is not supported.
The following table describes the version interoperability between Studio and InterSystems IRIS.
Studio Version | Compatible InterSystems IRIS Versions |
---|---|
2024.1 | 2018.1 through 2024.1 |
2023.2 | 2018.1 through 2023.2 |
2023.1 | 2018.1 through 2023.1 |
2022.1 | 2018.1 through 2022.1 |
2021.1 | 2018.1 through 2021.1 |