LabVIEW Idea Exchange

Showing results for 
Search instead for 
Did you mean: 

LTS (Long-term support) vewrsion of LabVIEW

Status: Declined
Thank you all for providing feedback on this idea. After carefully researching our options and talking to many customers about the possibilities, we have decided not to pursue a separate version of LabVIEW at this time. Instead, we have dedicated more resources to improving the stability and performance of our standard LabVIEW releases. The latest release, LabVIEW 2011, is an example of this emphasis, see here ( for more details. We plan to continue this type of emphasis for future releases.

I want to be able to work on STABLE versions of LV.


The last great stable version I remember was 6.1 (I never had 7.1).


2009 and 8.5.1 were not bad but please give us a feature-fixed long-term support version of LabVIEW.


For anyone unfamiliar with the idea, many Linux distributions offer the same:  Here's a link to the Ubuntu webpage outlining THEIR LTS strategy.



Active Participant

Thank you for your candor and your passion for this topic - perhaps I can provide some insights regarding how we're investing to address this need, as we definitely recognize the importance of providing a stable version of LabVIEW and have been making a number of changes towards that goal.


First and most importantly, our annual release cycle was not put in place as a means to mandate annual upgrading. Put another way, we do not expect or recommend that users who are mid-development would upgrade an existing project at the same cadence as our release cycle. Our official support policy ( states that we offer mainstream support for the last four versions of LabVIEW, which includes patches and critical bug fixes during this four-year time-frame. We recommend starting new projects using the latest version when developing, as this allows you to take full advantage of the four-year support window for the sake of long-term support, and it will include all of the updates and patches that were released for previous versions.


If projects require development over an extended time-frame, we recommend planning for periodic upgrades across a project's lifecycle, ideally at no longer than four year intervals. If a system is no longer under active development, planning for upgrades is likely unnecessary, as any major problems have historically been detected and addressed during the initial four-year window, if not much sooner. For anything beyond this four-year window, we are willing and able to put extended support contracts in place, as documented on the policy page.


We moved towards an annual release cycle as a result of some fundamental changes in how we develop and release software that were aimed at providing a better user experience. Prior to the annual cycle, our release cadence was unknown to users and therefore unpredictable, which made planning for upgrades and software maintenance difficult, thereby increasing the risk and level-of-effort required to migrate to a new version. Though the number of features over an extended timeframe is roughly the same, the change between annual versions is more incremental, which allows us to iterate and improve more regularly, incorporate support for new hardware, and most importantly, it decreases the risk associated with upgrading between versions, though we still recommend testing.


Internal changes to our development process has also helped improve the quality of versions upon release, and the new NI Error Reporting service ensures that we're focusing our efforts on the most problematic issues. On that note, please be sure to send us these reports if/when you have a problem, as they make it significantly easier for us to diagnose and reproduce these issues within R&D.


In summary, we provide critical patches and updates for every version of LabVIEW for four years, so we hope that this is a form of the long-term support you're seeking. These same updates are obviously rolled into new versions, but these new versions also incorporate new features that were not in previous versions. In practice, we rarely need to release critical updates beyond the first year, thanks to our increased focus on releasing more stable software and the fact that any problems that could adversely impact the behavior of a system are quickly found and addressed. Also, for those of you using newer versions, we've significantly improved how we notify and distribute critical updates and patches. Newer versions include the update service, which we use to make these available without having to manually download and install anything. As a member of our service program, it's up to you to decide when new features or new hardware support warrant upgrading existing systems to a later version, but this is not required for access to critical bug fixes.



Elijah Kerry - Senior Product Manager for LabVIEW

Elijah Kerry
Chief Product Manager, Software Platform
Follow my Software Engineering for LabVIEW Blog