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'sPluginInfo.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.