Upgrading base LabVIEW version

[ChrisStrykesAgain]

To be clear, I see immense value in supporting as many LabVIEW versions as possible. That said... the readme says Caraya is still developed against 2013. If that's the case, I'd argue it's time to bump that a bit... for reference, LabVIEW 2013 does not even formally support Windows 10, let alone 11.

As far as what version to go to, personally, I see LabVIEW 2020 as a line in the sand, given that it was the first year to have a Community version. I think that's a significant point, as it means that ANYONE can then contribute to the Caraya code base, rather than just corporate users. (It also has sets, maps and interfaces which I have found immensely valuable in many contexts, but that's really a side note at this point.)

Any thoughts?

[francois-normandin]

@ChrisStrykesAgain This has indeed been discussed (and agreed) with @jimkring to up the version to LV2020.

I've deferred doing it until the Core Test Manager is reworked to be decoupled from the UX part, but I have not had time to spare on this project for a long time. I am not against bumping the version to 2.0 and saving for LV2020 if it allows more folks to contribute actively!

Sets, Maps, interfaces and all those nice-to-have features don't have to be coupled to the base package though. It's perfectly efficient to create wrappers such as this discussion:
#183 (comment)

Maybe I'm wrong, but I feel like this is a more pragmatic development approach? I'd advocate for seeing if any of the extensions proposed are more sticky than others before rolling the concept in the base.

[ChrisStrykesAgain]

@francois-normandin, I'm not necessarily proposing that anything be refactored to use new language features as part of this effort, it was more a matter of them being available for future development if/when it makes sense. I think this effort should be as simple as just opening the project in 2020, saving, and committing.

That said, I think it would go very well with issue #71 which I'd also like to take a swing at. Are you open to me handling these two issues, independent of your Core Test Manager rework?

[francois-normandin]

By all means!
@ChrisStrykesAgain

[jimkring]

@ChrisStrykesAgain and @francois-normandin -- I'm in favor of this upgrade to LV2020. Have either of you started on this?

[francois-normandin]

@jimkring I had started a private branch to refactor the core, in LV2020, but this is stalled and I do not have bandwidth to continue that effort at this time.
I do not have a branch that consists only of a forward-save to 2020.

[jimkring]

Thanks for the update @francois-normandin.

What branch/dev approach would make sense? I noticed that master has the latest code and develop has fallen behind.
Should we rebase develop and create our PRs to merge into develop or target master?

(FWIW, lately I tend to just have a single main branch and do development in PRs that target this. I find that sync'ing develop to master is a bit of housekeeping work. Happy to take either approach.)

Also, I noticed that since nearly all the VIs are set to Separate Compiled Code, opening the VIs in LV2020 does not show the VIs with unsaved changes -- they need to be mass compiled to change their Save Version to 2020.

Would it assist your eventual completion of the core refactoring if we upgraded the project to LV2020 but don't actually mass compile anything? That way merge would be easier for you?

[francois-normandin]

@jimkring I'd target main/master through PRs.

You can mass compile to 2020. I'm pretty sure the eventual refactor would involve lots of changes, and my branch is really experimental at this time. I might restart once I have a valid concept.

[felipefoz]

Considering that we start to have support to save in older versions in LabVIEW 2024+ and if you don't want to do big jump, I would suggest to go with the oldest version that it supports to back save, which is 2017.

So, while you don't upset a lot a people by bumping to 2020 (including me), you can enable people to collaborate using the newest editor version.

[jimkring]

@felipefoz that's a great point. Some related thoughts...

• 2024 Q1 seems to have some bugs with Save Version (e.g. Find Regular Expression XNode get's broken, and a couple other nodes, too), which are fixed (I've heard) in 2024 Q3. I'm not sure if Caraya would be impacted by these issues, but I have a work project that is impacted by the Find RE bug.
• I do like the idea of being able to use Sets and Maps more extensively in code, which is part of the reason to upgrade the sources to LV2020+ and it's the first version to support LVCommunity Edition. So, that feels like a good "stake in the ground" so to speak.
• The nice thing is that even if we upgrade to LV2020 now, we can always/easily change the Save Version to 2017 later (assuming we don't go wild and rewrite things with Sets and Maps right away).

These are just thoughts. I think your point is valid @felipefoz and I'll be curious to see what the community (and especially maintainers/contributors) wants.