VIPM API: Allow major version number to be 0

[Joerg Hampel]

With VIPM 2020.3 (build 2540) and VIPM API 2020.0.2.73, it's not possible to supply a major number of 0 via the API, the API returns an error 42:

Seeing as we also build projects that are in a pre-v1.0 state, I don't see a reason to not allow the major build number to be 0.

I was actually tempted to file a bug report... 😉

[Jim Kring]

Hi Joerg,

Great idea. A couple comments/questions:

I see that the VI Package Builder GUI defaults to 1 for the major version, yet it allows changing it to 0. It also allows you to build and install such a package (with 0 as the major version), just fine. More so, I see there are several packages in the wild (on vipm.io) that use 0 as the major version number, too. So, it would seem reasonable to allow the VIPM API to support this, too, and it wouldn't introduce any new problems.

Which VIPM API VIs are you calling and how you're using it? I'm assuming you probably have an existing .vipb file and you're using "Read VI Package Build Spec.vi" and then "Write VI Package Build Spec.vi" to update a value such as the build number, as shown below.

Thanks for posting the idea and for your additional input.

[Joerg Hampel]

Jim, as always, your elaboration is spot on. Here's a screenshot of what our tools do:

So other than the fact that we write all the build numbers in one go (the whole cluster), it's what you described above.

Thanks for taking the suggestion into consideration.

[Jim Kring]

Thanks for the clarification on your use case -- it's very helpful (and exciting) to see the code in action that does the automated builds of your VI Packages!

We've done some work on a fix for this issue (we're calling it a "bug") and I'll ping you off-line so you can test it out, if you'd like.

[Joerg Hampel]

Yes, please, that would be great!

[sbasavaraj]

On 3/3/2021 at 10:35 PM, Jim Kring said:

Thanks for the clarification on your use case -- it's very helpful (and exciting) to see the code in action that does the automated builds of your VI Packages!

We've done some work on a fix for this issue (we're calling it a "bug") and I'll ping you off-line so you can test it out, if you'd like.

Is this issue fixed? The issue is still present in the 2020.0.2.73 version of VIPM API which appears to be the latest.

[Jim Kring]

hi @sbasavaraj.  I'll look into it.

@Joerg Hampel to you recall where this left off?

I've created an issue to track it, either way: https://github.com/vipm-io/vipm-desktop-issues/issues/14

We've been working on a real command-line interface, so I'm not sure if we actually updated the VI-based API.

[Joerg Hampel]

8 hours ago, Jim Kring said:

@Joerg Hampel to you recall where this left off?

Jim, you privately shared an unpublished version of VIPM (2020.0.3.80) with us back then, which we've been bundling with our tools ever since.

[Jim Kring]

OK, I was able to track down the fixed VIPM API package here:

VIPM API 2022.0.3.80 >> jki_lib_vipm_api-2020.0.3.80.vip

@sbasavaraj can you please try this and let me know if it works for you?

[Joerg Hampel]

On 10/7/2022 at 12:45 AM, Jim Kring said:

We've been working on a real command-line interface, so I'm not sure if we actually updated the VI-based API.

It would be great if that fix made it back into the official release. If at all possible, we'd prefer to keep using the API from our LabVIEW-based tools.

[Jim Kring]

2 hours ago, Joerg Hampel said:

It would be great if that fix made it back into the official release. If at all possible, we'd prefer to keep using the API from our LabVIEW-based tools.

Done. 👉 vipm.io/package/jki_lib_vipm_api/