Rationale to Upgrade Software
Developers find the need to upgrade software for various reasons. When new hardware is used in a system a developer needs to upgrade software to a supported version. Similarly, developers need to upgrade an application to utilize new software features. Other times, developers are forced to upgrade software because components of their system (operating systems, hardware, software, etc.) become obsolete. When the components are upgraded, developers need a compatible software version. In many situations a software upgrade is inevitable.
The main rationale to upgrade software regularly is to always have a mainstream supported software version in use. NI will release patches at their discretion for software with mainstream support. If bugs are found in software that are not covered by mainstream support it is not likely they will be fixed.
Another consideration for regular software upgrades is that whether you are updating for new hardware or software features, system component compatibility, or a bug fix, regular incremental upgrades will allow more seamless transitions than large version jumps. For example, upgrading every two software version releases will ensure continued mainstream support and need a substantially lower amount of effort than updating every six software version releases.
Software Upgrade Best Practices
When updating a small application it may be tempting to upgrade to the new software version and hope for the best. NI recommends using these best practices regardless of the application. The time and effort involved with these practices will scale appropriately with the size and complexity of each application.
For a comprehensive document on the best software upgrade practices, refer to Upgrading Your Version of LabVIEW. A general overview to software upgrade best practices is found below. The practices outline upgrading software from the current version to the upgrade version.
NI completes thorough testing on software before release to resolve any bugs that may be present; however, it is not possible to test every use case. Unknown bugs may present themselves during the upgrade process. Document any unknown bugs that arise. Isolate the behavior to a small code snippet and escalate the bug to NI. NI will create a Corrective Action Request (CAR) and release a patch or work around.
Problems can arise at any point of your application’s code. Code Modularity is a good programming practice that can help identify the source of any issues. Individual subVIs can be tested to find root causes of problems that occur and ultimately lead to a faster resolution.
Collaborate with other users in our discussion forums
A valid service agreement may be required, and support options vary by country.