2.6 KiB
Visionary PacketAV — BETA channel registry
A parallel copy of the production plugin registry that publishes a separate package identity for pre-release testing. Testers point Q-SYS at a different URL and get beta builds; everyone else stays on the production feed untouched.
What makes this the beta channel
| Production | Beta (this repo) | |
|---|---|---|
| Package id | Visionary-PacketAV-Suite |
Visionary-PacketAV-Suite-Beta |
| Library entry | Visionary PacketAV Suite | Visionary PacketAV Suite (Beta) |
| Add-package URL | https://vsplug.in/packetav |
https://vsplug.in/packetav-beta |
| In-plugin update feed | https://vsplug.in/versions |
https://vsplug.in/versions-beta |
| Notifications channel | VSI_PacketAV_Versions |
VSI_PacketAV_Versions_Beta |
| Version lineage | its own 3-part counter | its own 3-part counter |
Both packages live in the same Gitea org (visionary-plugins), because
Gitea owns NuGet packages at the org level. The distinct package id is what
gives Q-SYS a separate My Packages entry — cloning the repo alone would not.
Important: never run both channels on one machine
The beta plugins keep the same PluginInfo.Id as production so testers
exercise the real blocks. That means Designer will see two files with the same
id if both the prod and beta packages are installed, and one will shadow the
other unpredictably. A tester is on either prod or beta, never both.
See docs/BETA-tester-instructions.md.
Publishing a beta build
- Drop the beta
.qplugx(andicon.png+ any PDFs) intoplugins/VisionarySolutions_Suite_Beta/content/. - Bump
<version>inVisionarySolutions_Suite_Beta.nuspec(3-part SemVer, strictly higher than the last beta — never a 4-part number). - Commit and push to
main. - Actions → Publish Q-SYS plugins → Run workflow (manual by design).
- Update the beta update feed: replace
versions-beta.jsonin the assets repo so in-plugin update checks on beta builds see the new version.
Promoting a beta to production
When a beta build passes, the same .qplugx files move to the production
repo's content/, bump the production nuspec version, and publish there.
Nothing is rebuilt — the plugin files (and their PluginInfo.Ids) are identical;
only the package wrapper differs. Then update the production versions.json.
Everything else
CI, tools/pack.ps1, the SemVer rules, the anonymous-read requirement, and the
same PACKAGE_TOKEN secret all work exactly as in the production repo — see
that repo's README and docs/publishing-lessons.md.