General Upgrade Information
This section provides information on upgrading from earlier versions. InterSystems’ ultimate goal is to have a release which can be installed with no, or little, effect on the applications it supports.
The goal of each release is a smooth upgrade to new and improved functionality with no changes required to existing applications. However, because of error corrections, significant enhancements, or changes to applicable standards, this goal cannot always be met. In this case, InterSystems discloses all identified instances where changes to applications are necessary so that customers can gauge effort required to move to the new release.
You may, after reading the release-specific changes, conclude that none of them affect your application. Even in this case, regardless of how robustly designed and how well implemented your application is, there is no substitute for quality assurance test results that confirm your judgement and demonstrate the application remains unaffected by the upgrade.
InterSystems recommends that each application be thoroughly tested in the upgraded environment before it is deployed to customers and begins processing live data.
Toward the end of development for each release, InterSystems may make available a preview version of the product to its customers. Notifications of the preview are published on the website and on public blogs. The purpose of this is two-fold:
It provides an early opportunity for customers to determine how the changes and enhancement in the release affect existing applications, to report issues found, and verify those issues have been resolved.
It also provides early exposure of new features. Customers have a chance to try out the proposed ideas and give feedback on the usefulness of this feature for their business area.
InterSystems strongly encourages customers to plan on obtaining a preview release and to test their application against it.
InterSystems does not support upgrading from a preview version.
One of the goals for preview release is to expose the new release to real-world operating challenges to assure its reliability. Therefore, it is possible, although unlikely, that an unanticipated sequence of events may render InterSystems IRIS unresponsive. In this situation, it is extremely important to gather system diagnostic information while in the hung state for InterSystems to analyze. Should an instance of InterSystems IRIS become unresponsive,
This section contains specific instructions applicable to this transition.
Because a containerized application is isolated from the host environment, it does not write persistent data; whatever it writes inside the container is lost when the container is removed and replaced by a new container. Therefore, an important aspect of containerized application deployment is arranging for data to be stored outside of the container and made available to other and future containers.
The durable %SYS features enables persistent storage of instance-specific data — such as user definitions, audit records, and the log, journal, and WIJ files — when InterSystems IRIS is run in a container, allowing a single instance to run sequentially in multiple containers over time. For example, if you run an InterSystems IRIS container using durable %SYS, you can upgrade the instance by stopping the original container and running a new one that uses the instance-specific data created by the old one. For information about upgrading, see Upgrading InterSystems IRIS Containers
; for detailed information on durable %SYS, see Durable %SYS for Persistent Instance Data
InterSystems recommends that customers recompile all their classes contained in each namespace. This will assure that:
Subclasses derived from the InterSystems product library will see improved product behavior if a method call results in executing code in its superclass(es).
All embedded SQL will use the latest versions of the SQL infrastructure.
All projections involved in language bindings will be updated.
All generated routines and classes will be updated.
Class compiler version utility
To assist customers in determining which class compiler version a class or classes in a namespace have been compiled with, InterSystems provides two assists
This method returns the version of the class compiler used to compile this <classname> and the datetime the class was compiled
This query generates a report for the current namespace that includes all classes, the version of the compiler used to compile each one, and the datetime each was compiled. The first argument <sortby> may have the following values:
ObjectScript routines do not need to be recompiled after upgrade with the following exception:
Cached queries are always purged during upgrade. They are recompiled and cached as needed.
It is not necessary to re-import any Web Service Definition (WSDL) files.
When you upgrade InterSystems IRIS to a new major version, existing Query Plans are automatically frozen. This ensures that a major software upgrade will never degrade the performance of an existing query. For performance-critical queries, you should test if you can achieve improved performance. For details, see Software Version Upgrade Automatically Freezes Plans
in the InterSystems SQL Optimization Guide.
Content Date/Time: 2019-08-23 05:52:04