Beta channel scaffold
This commit is contained in:
Joe Peavey
@@ -0,0 +1,67 @@
|
||||
# Joining the Visionary PacketAV Beta
|
||||
|
||||
Thank you for helping test pre-release builds. The beta plugins are the real
|
||||
blocks that will ship — you're seeing them a cycle early. Setup is the same as
|
||||
the normal plugins, just a different URL.
|
||||
|
||||
## Before you start — one rule that matters
|
||||
|
||||
**Do not have both the regular and the beta Visionary PacketAV packages
|
||||
installed on the same computer.** The beta plugins share the same internal IDs
|
||||
as the production plugins (that's what makes them a true test), so if Q-SYS
|
||||
Designer finds both, it can silently load the wrong one. Pick one channel per
|
||||
machine:
|
||||
|
||||
- Testing beta? Remove the regular **Visionary PacketAV** personal package
|
||||
first (below), then add the beta one.
|
||||
- Done testing? Do the reverse to go back to production.
|
||||
|
||||
A dedicated test computer is ideal if you have one.
|
||||
|
||||
## Add the beta package
|
||||
|
||||
1. Sign in at `https://library.qsys.com`, then **My Library → My Packages**.
|
||||
2. If the regular **Visionary PacketAV** entry is present, select it and
|
||||
**remove** it first (see "Leaving the beta" for why this is safe).
|
||||
3. Click **Add Personal Package** and enter:
|
||||
- **Asset name:** `Visionary PacketAV (Beta)`
|
||||
- **Package URL:** `https://vsplug.in/packetav-beta`
|
||||
4. Click **Add package**. You'll see the "Personal Package Added" confirmation.
|
||||
|
||||
## Install in Q-SYS Designer
|
||||
|
||||
1. Open **Q-SYS Designer** and sign in to the **same** Library account.
|
||||
2. **Tools → Show Asset Installer**.
|
||||
3. On **Available Assets**, find **Visionary-PacketAV-Suite-Beta** and click
|
||||
**Install**. Wait for **Install Status = Complete**.
|
||||
4. The plugins appear under **Visionary** in the schematic Plugins list, same
|
||||
as always. (Tip: check the plugin's **Help** page — beta builds are marked
|
||||
so you always know which channel you're on.)
|
||||
|
||||
## Getting new beta builds
|
||||
|
||||
When a new beta is published, the Asset Installer shows a higher **Latest
|
||||
Version** than your **Local Version** — click **Install** to update. If it isn't
|
||||
showing yet, click **Refresh**; if that's stale, remove and re-add the
|
||||
`https://vsplug.in/packetav-beta` entry (that forces a fresh read).
|
||||
|
||||
The plugins also tell you in-product: the **Software Update** line on the Help
|
||||
page checks the beta feed and reports when a newer beta is available.
|
||||
|
||||
## Reporting issues
|
||||
|
||||
Please include: plugin and version (from the Help page footer), Q-SYS Designer
|
||||
version, Core model, and what you expected vs. what happened. Send to
|
||||
`support@visionary-av.com` or use the links at `https://vsplug.in/resources`.
|
||||
|
||||
## Leaving the beta / going back to production
|
||||
|
||||
1. **My Packages** → remove the **Visionary PacketAV (Beta)** entry.
|
||||
2. Add the production package back: **Add Personal Package** →
|
||||
name `Visionary PacketAV`, URL `https://vsplug.in/packetav`.
|
||||
3. In **Asset Installer**, install the production suite over the beta. Because
|
||||
the plugin IDs match, your existing designs keep working — they just move
|
||||
back to the released version.
|
||||
|
||||
Removing a personal package only detaches the feed; it doesn't touch designs
|
||||
you've already built.
|
||||
@@ -0,0 +1,111 @@
|
||||
# Beta channel — one-time setup runbook
|
||||
|
||||
Goal: stand up a beta feed that Q-SYS testers can add without touching the
|
||||
production feed. You do this once; after that, publishing a beta is just the
|
||||
five steps in the README.
|
||||
|
||||
Placeholders used below (matching your production setup):
|
||||
- Gitea host: `3f4dzl.gitea.cloud`
|
||||
- Org: `visionary-plugins`
|
||||
- Beta package id: `Visionary-PacketAV-Suite-Beta`
|
||||
|
||||
---
|
||||
|
||||
## 1. Create the beta repo in Gitea
|
||||
|
||||
Same org as production (packages are owned by the org, so the beta package will
|
||||
sit alongside prod in the org's Packages list — that's expected).
|
||||
|
||||
1. In Gitea: **`visionary-plugins` org → New Repository**.
|
||||
2. Name it `qsys-plugin-registry-beta`. Set visibility however you like —
|
||||
**repo visibility does not affect the feed.** The package feed's anonymous
|
||||
readability comes from the **org** being Public, which it already is for
|
||||
prod. (If the org is Public, the beta package is anonymously readable too.)
|
||||
3. Push this scaffold to it:
|
||||
|
||||
```bash
|
||||
cd qsys-plugin-registry-beta
|
||||
git init -b main
|
||||
git add .
|
||||
git commit -m "Beta channel scaffold"
|
||||
git remote add origin https://3f4dzl.gitea.cloud/visionary-plugins/qsys-plugin-registry-beta.git
|
||||
git push -u origin main
|
||||
```
|
||||
|
||||
## 2. Add the publish token
|
||||
|
||||
Same token as production works — a Gitea PAT with **package read/write** scope
|
||||
is org-wide, so it can publish `Visionary-PacketAV-Suite-Beta` too.
|
||||
|
||||
- Beta repo → **Settings → Actions → Secrets** → add **`PACKAGE_TOKEN`** with
|
||||
the same value you used for the prod repo.
|
||||
- Confirm a runner is available to the repo (Settings → Actions).
|
||||
|
||||
## 3. Publish a first beta build
|
||||
|
||||
1. Put a beta `.qplugx` set (or just copy the current prod content for a
|
||||
smoke test) + `icon.png` into
|
||||
`plugins/VisionarySolutions_Suite_Beta/content/`.
|
||||
2. Commit and push.
|
||||
3. Actions → **Publish Q-SYS plugins → Run workflow**.
|
||||
4. Verify the feed the same way as prod, anonymously:
|
||||
|
||||
```bash
|
||||
curl https://3f4dzl.gitea.cloud/api/packages/visionary-plugins/nuget/registration/Visionary-PacketAV-Suite-Beta/index.json
|
||||
```
|
||||
|
||||
You should see JSON listing the beta version(s).
|
||||
|
||||
## 4. Cloudflare short-links (301 redirects)
|
||||
|
||||
Add two aliases next to your existing `packetav` / `versions` rules. Point them
|
||||
at the beta package's registration URL and the beta versions file.
|
||||
|
||||
| Short link | 301 target |
|
||||
|---|---|
|
||||
| `vsplug.in/packetav-beta` | `https://3f4dzl.gitea.cloud/api/packages/visionary-plugins/nuget/registration/Visionary-PacketAV-Suite-Beta/index.json` |
|
||||
| `vsplug.in/versions-beta` | raw URL of `versions-beta.json` in your assets repo, e.g. `https://3f4dzl.gitea.cloud/visionary-plugins/assets/raw/branch/main/versions-beta.json` |
|
||||
|
||||
Then, in a browser (logged out), open `https://vsplug.in/packetav-beta` and
|
||||
confirm it lands on the registration JSON — QSC's backend must be able to
|
||||
follow the redirect, exactly as it does for the prod link.
|
||||
|
||||
## 5. Seed the beta update feed
|
||||
|
||||
Put `versions-beta.json` (in this repo's `docs/`) into the **assets** repo root
|
||||
so `vsplug.in/versions-beta` resolves. Keep its `package` value equal to the
|
||||
beta nuspec `<version>` and the `plugins` map equal to the beta build's plugin
|
||||
versions. Update it every time you publish a new beta.
|
||||
|
||||
## 6. Beta icon (optional but recommended)
|
||||
|
||||
The nuspec references `icon-beta.png` in the assets repo so beta is visually
|
||||
distinct in Asset Installer. Drop a beta-badged icon there, or change the
|
||||
`iconUrl` back to the prod `icon.png` if you'd rather not bother.
|
||||
|
||||
---
|
||||
|
||||
## Version lineage rules (same discipline as prod)
|
||||
|
||||
- Beta `<version>` is **3-part SemVer only** — a 4-part number makes the whole
|
||||
package vanish from Asset Installer.
|
||||
- Strictly ascending. The beta counter is **independent** of the prod counter;
|
||||
don't try to keep them in sync.
|
||||
- No prerelease `-beta` suffix on the number itself — Q-SYS filters those. The
|
||||
channel separation is the package id, not a version tag.
|
||||
|
||||
## Promotion flow (beta → production)
|
||||
|
||||
1. Copy the **same** `.qplugx` files from the beta `content/` into the prod
|
||||
repo's `content/`.
|
||||
2. Bump the **production** nuspec `<version>`.
|
||||
3. Commit/push and run the prod publish workflow.
|
||||
4. Update the prod `versions.json`.
|
||||
|
||||
Because the plugin files (and their PluginInfo.Ids) are byte-identical, this is
|
||||
a re-wrap, not a rebuild — what testers validated is exactly what ships.
|
||||
|
||||
## Retiring a beta build
|
||||
|
||||
Delete old beta versions from the org's Packages page anytime — beta has no
|
||||
field-install guarantees, so same-version delete/republish is fine here.
|
||||
@@ -0,0 +1,46 @@
|
||||
# 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`:
|
||||
|
||||
```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`:
|
||||
|
||||
```json
|
||||
{"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's `PluginInfo.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.
|
||||
@@ -0,0 +1 @@
|
||||
{"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"}}
|
||||
Reference in New Issue
Block a user