Testing and Releases

Testing and releases

Local verification

The baseline suite is:

pnpm run ci:all

It covers Rust formatting, strict Clippy, Rust tests, frontend formatting, frontend linting, and the frontend production build.

Native adapter probes are available on their respective platforms:

cargo run -p sonos-volume-bridge-platform-audio --example windows_audio_probe
cargo run -p sonos-volume-bridge-platform-audio --example macos_audio_probe

The test-support crate provides a local RenderingControl mock server and recorded XML fixtures. Mock and unit validation does not replace physical Sonos and operating-system testing.

Hardware acceptance

Every release candidate should verify:

• Discovery, stable selection, and reconnect.
• Computer-to-Sonos volume and mute.
• Sonos-to-computer behavior with two-way synchronization.
• Maximum-volume enforcement and mapping behavior.
• Event subscription, renewal, polling fallback, and recovery.
• Default and fixed output replacement.
• Clean shutdown and restart.
• Platform signing, installation, startup, and uninstall behavior.
• On Ubuntu, PulseAudio and PipeWire compatibility, pactl availability, default and fixed sink behavior, tray visibility, and Debian package installation.

Record only non-sensitive model, operating-system, firmware, and pass/fail information. Do not publish serial numbers, network addresses, raw diagnostics, or crash payloads.

Release flow

The Release workflow runs from develop, increments the single Cargo workspace version, validates that exact commit, builds Windows, macOS, and Ubuntu AMD64 packages, creates the annotated version tag, and publishes GitHub release assets. GA releases also submit the Windows Store package after GitHub publication.

Release channels are:

• GA for a full generally available release.
• Beta for broader testing before general availability.
• Alpha for early testing.

The workflow merges no branches. After a successful full release, develop is merged into main through the project process.

Wiki release policy

This wiki is maintained on its single GitHub default branch, currently master. It is updated only after a full GA release succeeds. Working branches, alpha releases, beta releases, and other prerelease builds must not change the documented user baseline.

Before a wiki update:

1. Confirm the GitHub release is not marked as a prerelease.
2. Confirm it is returned by the repository's latest-release endpoint.
3. Use the released tag as the source of truth for features, settings, defaults, assets, and limitations.
4. Recheck issue state before changing any limitation link.
5. Update the version banner and validate all internal and external links.