Make LabVIEW 2023 the minimum supported version for the open source icon editor

[svelderrainruiz]

@crossrulz flagged how easy it would be to support only LabVIEW versions beginning on LabVIEW 2023, and i agree with him. I am placing this discussion here to grab additional input or concerns before taking the decision.

[svelderrainruiz]

@gregr-ni Do you see any concerns or work that we should do that you are aware of?

[gregr-ni]

Certainly simplifies things if we can just support installing into LVAddons. The main downside is that people in earlier versions couldn't get any fixes/enhancements done here.

We could keep the source in an earlier version but have the installer require >=23. This would allow someone who really wants it to manually replace the files in earlier versions. They just wouldn't get the ease of the installer.

[crossrulz]

Why 2021?

• Community Edition started with 2020, so that argument is out.
• There is a tradition from NI to support drivers with the previous 3 versions of LabVIEW (ex DAQmx 2024 would support back to LabVIEW 2020). But we are talking about LabVIEW itself, so I don't see this as a strong argument. Not to mention that the development was in 2021 in the year 2024, breaking the tradition.
• The only real argument I can think of is 2021 was the last version before the disastrous subscription model came out. From the outside, it appears it was determined that this one project in the core of LabVIEW should still support those who refused to upgrade since.

If I wanted to be pure in my opinion, I would push for developing in whatever version NI initially puts the Icon Editor in lvaddons. The IE would be its own NI package and all somebody would need to do for a bug fix or upgrade would be to install a newer package. I know this hasn't happened yet, but that would be my goal in the next few years as it would be the simplest solution for everybody, developers and users.

My compromise is to push to 2023, when lvaddons is first supported. This makes installs simpler as a user only needs to install it once and it will work with any newer version. The installer will need to remove the current IE to make sure the lvaddons version is used.

[crossrulz]

While trying to save things to 2020, I discovered the LocalHost.LibraryPaths ini token does not work in 2020. This tells me the beginning of the LVAddons started in 2021. Due to the development process we were given, this kept us in 2021.

[JayKayAce]

just adding that it would be nice to make use cases for the new 2025Q1 VI comparison and comparison reports here as well.

• we can have a pipeline that builds the code in 2021. ✅
• 2025 should edit the code but save as 2021.
• VI Comparison should not change the source code.

I do not advocate that we should do this for every new LabVIEW Release but it would make sense to me here

[svelderrainruiz]

Still missing an answer from me regarding why are we using 2021 @crossrulz

[crossrulz]

We are also seeing issues with the font size between developing in 2024 (right) and 2021 (left).

This appears to be from a feature released in 2023Q1 (https://forums.ni.com/t5/LabVIEW-Idea-Exchange/Same-Height-of-Unbundle-by-Name-Terminal-Local-Variable/idi-p/1298608)

[svelderrainruiz]

I am forcing the VIPB to have LV2023 as earliest version.

[crossrulz]

It was decided in the SteerCo meeting today to change the save version to 2020. This decision was made to be consistent with the Actor Framework, the first version of LabVIEW Community, and the general agreement in the community to use 2020 for open source. This effort will be done once the current PRs are closed and the CI is in a good state.

[crossrulz]

Issue #456 was created

[crossrulz]

The VIs in the repo are now saved in 2020. We may need to update LabVIEW versions in the future due to new features and/or supported infrastructure.