proposal Should OpenG Move to vi.lib?

[asbo]

Definitely don't do the move piecemeal - all or nothing. If you want to trial it, make better versions available for brave adventurers to try on their own.

[crelf]

  On 9/7/2011 at 8:50 PM, Val Brown said:

Doing things right from the beginning (or as soon as possible for retroactive situations) ALWAYS pays off in the long run. If not then we all ought to just be jusing shifts and FGVs, typedef clusters....

[jgcode]

So, to summarize, the majority of users would support this move (and that we would do it atomically all in one release avialable at the same time)?

[gb119]

  On 9/10/2011 at 8:43 AM, jgcode said:

(and that we would do it atomically all in one release avialable at the same time)

And with a bump in the major version of all packages please so that it's really obvious when it's happened....

[Aristos Queue]

You're going to be forcing a relink of any existing VIs that expect to find their subVIs in user.lib but now find them in vi.lib. That's going to be a source-code level change for caller VIs (updating their saved subVI paths). It also means anyone loading any of these VIs dynamically needs to update their code. This is, in many ways, a change that breaks backward compatibility.

Does VIPM give you any way to give feedback to users about the effects of a particular upgrade at the time that they choose to upgrade? If so, you probably want to employ that mechanism.

Given that, I can imagine some people wanting to have both the user.lib and the vi.lib versions installed on the same LabVIEW. You could choose to not call this an upgrade but instead issue brand new packages, deprecating the ones in user.lib. That way people don't see these new versions as "upgrades" but actual new tools, which they would only adopt for new projects, and might continue to use the existing user.lib packages for existing projects.

[jgcode]

Great points, thanks for the feedback.

  On 9/12/2011 at 2:59 PM, Aristos Queue said:

It also means anyone loading any of these VIs dynamically needs to update their code. This is, in many ways, a change that breaks backward compatibility.

If the user linked to the VIs correctly this will not be an issue (i.e. will not break any code).

There is a OpenG VI that defines the OpenG directory.

Therefore, for this move it is noted that:

• The OpenG Library VI will need to be updated
  
• Underlying sub folder structure will not change
  

  On 9/12/2011 at 2:59 PM, Aristos Queue said:

You're going to be forcing a relink of any existing VIs that expect to find their subVIs in user.lib but now find them in vi.lib. That's going to be a source-code level change for caller VIs (updating their saved subVI paths).

This should be ok? Given that the user chooses to upgrade to the newer version, they will need to except that a recompile will be required. LabVIEW should handle this automatically (as reported earlier from my testing). However, we could even provide a VI to be downloaded that is an OpenG VI Tree containing all OpenG VIs so the user could open it first, then open their project code. The VI Tree will have the OpenG VIs in memory and LabVIEW will link to these on opening the user's code. (then they just do a save).

  On 9/12/2011 at 2:59 PM, Aristos Queue said:

Does VIPM give you any way to give feedback to users about the effects of a particular upgrade at the time that they choose to upgrade? If so, you probably want to employ that mechanism.

Yes, we have been using that feature since switching to VIPM and will continue to do so.

As mentioned above, this would also be a major release e.g. v5).

  On 9/12/2011 at 2:59 PM, Aristos Queue said:

Given that, I can imagine some people wanting to have both the user.lib and the vi.lib versions installed on the same LabVIEW. You could choose to not call this an upgrade but instead issue brand new packages, deprecating the ones in user.lib. That way people don't see these new versions as "upgrades" but actual new tools, which they would only adopt for new projects, and might continue to use the existing user.lib packages for existing projects.

I (personally) cannot think of a reason users would have both installed?

So I am thinking upgrades would be preferable for this.

[lvb]

Just wanted to chime in that I support the move. It should be all at once with a bump in the version number. Given the nature of the change, does it justify a "major" version increment?

[jgcode]

  On 9/15/2011 at 1:24 PM, brianafischer said:

Given the nature of the change, does it justify a "major" version increment?

I would think most definitely (this is just my personal opinion at the moment).

[Val Brown]

  On 9/15/2011 at 1:24 PM, brianafischer said:

Just wanted to chime in that I support the move. It should be all at once with a bump in the version number. Given the nature of the change, does it justify a "major" version increment?

  On 9/15/2011 at 1:42 PM, jgcode said:

I would think most definitely.

Yes definitely it's a major release with a significant change like this -- which is being handled very well IMHO given all that you've said.

[jgcode]

  On 9/15/2011 at 2:57 PM, Val Brown said:

which is being handled very well IMHO given all that you've said.

The OpenG Board will make the final decision on changes related to the direction of OpenG, but by all means, everyone's opinions, ideas and feedback are very much welcome and respected - so please keep them coming.

[GregSands]

  On 9/15/2011 at 2:57 PM, Val Brown said:

Yes definitely it's a major release with a significant change like this -- which is being handled very well IMHO given all that you've said.

Another "major change" that may be worth considering at the same time is whether to put the OpenG packages into .lvlib libraries. Pros and cons?

[jgcode]

  On 9/15/2011 at 9:55 PM, GregSands said:

Another "major change" that may be worth considering at the same time is whether to put the OpenG packages into .lvlib libraries. Pros and cons?

Please keep this thread on topic.

But, by all means, create a new thread to discuss new ideas (other than moving to vi.lib)!!

In this case, this thread already exists here: Migration of OpenG Projects to LabVIEW Project Libraries?

Cheers

-JG

[Ton Plomp]

I was just building a tool and wanted to include OpenG as sub-vis of the tool.

And that is possible, I can uncheck the 'exclude files from user.lib' to achieve that.

However if we move OpenG to vi.lib we cannot use the 'exclude files from vi.lib'. Since that would include a lot of internal vi.lib stuff...

So in a blink of a second I changed from 'YES' to 'NO'

[Jim Kring]

  On 10/10/2011 at 6:42 PM, Ton Plomp said:

I was just building a tool and wanted to include OpenG as sub-vis of the tool.

And that is possible, I can uncheck the 'exclude files from user.lib' to achieve that.

However if we move OpenG to vi.lib we cannot use the 'exclude files from vi.lib'. Since that would include a lot of internal vi.lib stuff...

So in a blink of a second I changed from 'YES' to 'NO'

Ton: Can you explain more about your use case? For example, the type of tool you are building, what you're using to build your tool (OpenG Builder, LabVIEW Application Builder), and why you need to exclude OpenG but include other vi.lib stuff?

[Ton Plomp]

I'm currently using NI Source distribution builder together with VIPM to create a LVTN version of the Code Capture Tool.

One of our (mine and Yair) targets is to be independent on other tools like OpenG (however when using VIPM that is very unlikely).

So I made a source distro with LabVIEW, and included any stuff in user.lib (OpenG) and excluded vi.lib.

Just for fun I embedded vi.lib, and the support folder went from 500 kb (OpenG) to 2.8 MB (including all the config files for instance).

Ton

[jgcode]

  On 10/10/2011 at 6:42 PM, Ton Plomp said:

And that is possible, I can uncheck the 'exclude files from user.lib' to achieve that.

FWIW, I also commented on this previously here

[Jim Kring]

  On 10/12/2011 at 6:55 PM, Ton Plomp said:

I'm currently using NI Source distribution builder together with VIPM to create a LVTN version of the Code Capture Tool.

One of our (mine and Yair) targets is to be independent on other tools like OpenG (however when using VIPM that is very unlikely).

So I made a source distro with LabVIEW, and included any stuff in user.lib (OpenG) and excluded vi.lib.

Just for fun I embedded vi.lib, and the support folder went from 500 kb (OpenG) to 2.8 MB (including all the config files for instance).

Ton

Have you tried building your Code Capture Tool using VIPM's package builder? It excludes stuff in vi.lib and has the option to include or exclude individual OpenG packages.

[gb119]

  On 10/12/2011 at 10:31 PM, Jim Kring said:

Have you tried building your Code Capture Tool using VIPM's package builder? It excludes stuff in vi.lib and has the option to include or exclude individual OpenG packages.

Ummmm I get this funny feeling of a conversation going in circles here....

What order does the general policy (e.g. exclude vi.lib) and the package specific rules (e.g. but include OpenG packages) get applied in ? If the individual package (in|ex)clusions are taken after the blanket vi.lib rules then it sounds like Ton should be able to build his package even if OpenG were to move to vi.lib (assuming also that the package specific rule handled dependencies, so that if include the OpenG meta package in my build it includes all of the vis in all of the OpenG packages...).

[jgcode]

  On 10/12/2011 at 10:43 PM, gb119 said:

Ummmm I get this funny feeling of a conversation going in circles here....

What order does the general policy (e.g. exclude vi.lib) and the package specific rules (e.g. but include OpenG packages) get applied in ? If the individual package (in|ex)clusions are taken after the blanket vi.lib rules then it sounds like Ton should be able to build his package even if OpenG were to move to vi.lib (assuming also that the package specific rule handled dependencies, so that if include the OpenG meta package in my build it includes all of the vis in all of the OpenG packages...).

There are two build processes being discussed here: LabVIEW Builder and VIPM. They should not be confused with each other.

[lordsathish]

  On 9/3/2011 at 7:08 PM, Aristos Queue said:

Now, on the flip side, NI might decide to move vi.lib out of Program Files under such a scenario. There's lots of possibilities here. So, it's not necessarily a showstopper, but I'd suggest you investigate MS' Windows 8 plans before deciding this issue.

Does NI has plans to move vi.lib to ProgramData ? This seems to be a likely plan for NI. If addons have to be installed into vi.lib, it should be outside Programfiles for other applications to have access. Then there is a possibility that user.lib is separate for each user and is moved to AppData of each user. If Addons go into user.lib that is different for each user, that doesn't make sense. That could be the reason why NI is recommending Addons to be moved into vi.lib

I'm making lot of guess. Someone should comment on what part of it is really possible.