lvpm 0.2.1

Bug-fix release. If you use lvpm with any LabVIEW older than 2026, you want
this one — on 0.2.0 and earlier, relinking failed on every package there.

Fixed: every package failed to relink on LabVIEW 2025 (error 122)

Installing any package into a LabVIEW older than 2026 failed at the first
VI Server method call:

...\vi.lib\Wiresmith Technology\G CLI ... FAILED
    invoking Ctrl Val.Set on 0x14d00017: VI Server returned error 122

Error 122 is "the resource you are attempting to open was created in a more
recent version of LabVIEW and is incompatible with this version". Because it
names a resource, it reads like a broken or too-new VI. It was the wire format.

Every flattened value lvpm sent carried a LabVIEW 2026 version stamp. A server
unflattens data stamped at or below its own version and rejects anything above
it. Relinking a folder begins by setting the folder control, so the stamp failed
every package on an older LabVIEW while working perfectly on 2026.

Flattened data is now stamped LabVIEW 2020, the oldest release lvpm supports and
the version the bundled relink VI is saved for.

This is not the handshake. That stamp is tolerated in both directions — a 2025
server accepts a client claiming 2026 — which is why the connection came up
cleanly and only the first method call failed.

Verified on a live LabVIEW 2025 (64-bit) v25.3: the call that returned 122 now
succeeds and the VI runs.

Fixed: the install script

• The final line ran lvpm --version with a trailing &. On PowerShell 7 that
  is the background operator, so the version never printed and the run ended on
  the bare word installed. On Windows PowerShell 5.1 the script did not parse
  at all, against its own #Requires -Version 5.1. It now prints
  lvpm 0.2.1 installed.
• .\install.ps1 with no arguments always failed with no release found.
  Invoke-RestMethod returns a JSON array as one object, so the release filter
  tested the whole array instead of each release. Pinning a tag with -Version
  was unaffected, which is what made it look like a permissions problem.
• The README now says to cd somewhere writable first. An elevated PowerShell
  starts in system32, where the download cannot be written, and the resulting
  access-denied error looks like a network failure.

Install

cd $env:TEMP
irm https://raw.githubusercontent.com/Flydroid/lvpm/main/scripts/install.ps1 -OutFile install.ps1
.\install.ps1

If lvpm still reports an old version afterwards, check for a copy left by
cargo install in %USERPROFILE%\.cargo\bin, which comes earlier on PATH
than the install directory and will shadow it.

Verifying the download

The zip's SHA-256 is recorded by GitHub as the asset digest and shipped in
SHA256SUMS. The install script checks both. By hand:

Get-FileHash -Algorithm SHA256 .\lvpm-0.2.1-windows-x64.zip

90d20ec6c03b4a45a52973cc5adfee31fc14f8c55b8ab72962384243adfa488f

Known limitations

• LabVIEW must be running for lvpm to relink; lvpm starts it when it is not,
  except in a headless run. Note that LabVIEW accepts a TCP connection on the
  VI Server port several seconds before it will answer a handshake, so a
  readiness check based on the port alone reports ready too early.
• In LabVIEW 2026 the relink VI is initially blocked because it comes from an
  untrusted source.
• Hook VIs' own error out is not read back. No mass compile. Windows only.

Not affiliated with JKI or NI.