53 lines
2.6 KiB
Markdown
53 lines
2.6 KiB
Markdown
# 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`.
|