Branch surfing and asset reuse on publish

Branch surfing

Internal release builds (a com.myapp.uat mirror on TestFlight or a Play internal track) can switch between branches from inside the app. A channel gets a switch and a glob pattern, for example pr-*. A device on that channel can ask for any branch matching the pattern. A request for a branch that does not match is ignored and the device gets its normal update. The default pattern is empty and empty matches nothing.

A control center package turns itself on when the build's channel allows surfing and lists the matching branches. If switching to a branch causes a native error, surfing is blocked for that update and the device rolls back to the default branch. The block is per update, so publishing a fix to the same branch makes it available again.

Publish skips assets that did not change

Asset keys are scoped per update, so every publish used to re-upload everything. When the CLI requests upload URLs, the server now reads the previous update's metadata.json on the same app, branch, runtime version and platform, copies every matching file into the new update server-side, and returns upload URLs only for the remaining files.

eoas publish

• --upload-rate caps the asset upload speed and the initial burst.
• Uploads retry after rate-limit and server errors with capped exponential backoff, honouring the delay the server sends.
• A 401 now hints at a missing EOO_TOKEN.
• The republish endpoints stay compatible between a 3.1.1 CLI and a 3.1.2 server, and the other way round.

Dashboard

• The updates list paginates with a cursor. Contributed by @lyric777.
• The rollout view shows the updates of every platform. Contributed by @floze-the-genius.

Server

• Assets are served with their real content type.
• Per-client Prometheus tracking is skipped when PROMETHEUS_ENABLED is unset. Contributed by @ssompally.
• Each deployment gets a persistent instance id and sends an hourly usage heartbeat (instance id, server version, storage and database configuration, base URL). Opt out with DISABLE_TELEMETRY=true.

Enterprise licenses

Activation goes through a server-side verification step with a confirmation dialog. Licenses are re-validated online periodically. When validation fails, the deployment enters a 7-day grace period instead of stopping, and a banner in the dashboard tells every user. The License page shows organization, plan, subscription and last verification. A license.suspended audit event records the state change.

Deploy

docker pull ghcr.io/mercuretechnologies/xprem:v3.1.2
helm install xprem oci://ghcr.io/mercuretechnologies/charts/xprem --version 3.1.2