Files
2026-07-23 23:43:18 -04:00

2.0 KiB

update_check.lua — beta build changes

The update-check code is identical between channels except for two constants at the top, plus the per-build PackageVersion that already lives in each .qplug. Point beta builds at the beta feed and give them their own Notifications channel so a beta instance and a prod instance never elect each other (belt-and-suspenders — testers shouldn't be running both anyway).

Change these two lines in the beta build's update_check.lua:

local CH           = "VSI_PacketAV_Versions_Beta"      -- was: VSI_PacketAV_Versions
local VERSIONS_URL = "https://vsplug.in/versions-beta"  -- was: https://vsplug.in/versions

Everything else — leader election, gateway check, applyVersions, Check Now — is unchanged.

PackageVersion

In each beta .qplug, set the PackageVersion constant to the beta package's version (the beta nuspec <version>), not the prod counter. That's what the update check compares against versions-beta.json's package field to decide "a newer beta exists." Your stamp_package_version.py helper does this; run it against the beta build folder with the beta version.

versions-beta.json shape

Same schema as prod versions.json, hosted at vsplug.in/versions-beta:

{"package":"1.0.0","plugins":{"Visionary~Decoder":"5.2.3","Visionary~Encoder":"5.2.3","Visionary~Router":"5.2.3","Visionary~IR Driver":"5.2.3"}}
  • package = beta nuspec <version> for the latest beta build.
  • plugins = each beta plugin's PluginInfo.Version (typically ahead of prod).

annotate_qplugx.py already emits a versions.json from a build folder; for beta, publish that output as versions-beta.json in the assets repo.

Optional: mark the Help page as beta

Since the plugin IDs match prod, add a small "BETA CHANNEL" tag on the Help page (and/or set the beta plugins' PluginInfo.Version build field distinctly) so a tester glancing at the schematic always knows which channel is loaded. This is the same Software Update group from the prod mockup, just with a beta label.