Beta channel scaffold

2026-07-23 23:43:18 -04:00
commit 6c34d89a2f
14 changed files with 647 additions and 0 deletions
@@ -0,0 +1,52 @@
+# 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
+
+1. Drop the beta `.qplugx` (and `icon.png` + any PDFs) into
+   `plugins/VisionarySolutions_Suite_Beta/content/`.
+2. Bump `<version>` in `VisionarySolutions_Suite_Beta.nuspec` (3-part SemVer,
+   strictly higher than the last beta — **never** a 4-part number).
+3. Commit and push to `main`.
+4. Actions → **Publish Q-SYS plugins** → **Run workflow** (manual by design).
+5. Update the beta update feed: replace `versions-beta.json` in 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`.