# 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`.