_Mirrored from the GitHub release v2.2.0; the downloads are served from https://download.waveflow.app._ # WaveFlow Server 2.2.0 The server can now tell its administrators when a new version is out, after asking them first. Every release also gains a second place to download it from, one that does not depend on GitHub. The database gains one table, so read [Upgrading](#upgrading-from-212) before you pull. ## New - **Being told a new version is out.** 2.1.1 and 2.1.2 were security releases, and nothing told the person running a server that they existed. Now the first administrator who signs in after the upgrade is asked whether the server may check `download.waveflow.app` for new versions: once shortly after each start, then once a day, and at once when the check is turned on. **Nothing is sent before the answer is yes**, so a server left at its defaults still contacts nobody on its own. Once the check is on, a dialog names the new version when one is out, links its release page, and says how to update a container or an archive. It can be dismissed for that version: the next release is announced again. Settings › Administration holds the switch and says when the server last checked. Only administrators see any of it. The request fetches a small file, `server/stable.json`, or `server/beta.json` on a pre-release. It carries the server's version in its User-Agent and nothing else about the server: no identifier, no account, no count of anything. The host sees the address the request comes from, as any host contacted does. [What leaves the server](https://github.com/InstaZDLL/waveflow-server/blob/v2.2.0/docs/guides/privacy.md#the-update-check-downloadwaveflowapp) says exactly what is sent and when. Two settings decide for an operator who would rather not be asked. `WAVEFLOW_UPDATE_CHECK` is `ask` by default; `on` checks without asking, and `off` never checks and asks nobody. `WAVEFLOW_UPDATE_URL` names another folder, for a fork that publishes its own. The decisions are in [RFC-028](https://github.com/InstaZDLL/waveflow-server/blob/v2.2.0/docs/rfcs/RFC-028-update-check.md), and the change is [#435](https://github.com/InstaZDLL/waveflow-server/pull/435). This is the first release that can tell you about the next one. A server older than 2.2.0 has no check, so this one you still have to hear about the old way. - **A second place to download from.** Each release's archives, their `SHA256SUMS`, the FFmpeg sources and the release notes are now also published on `download.waveflow.app`. The folder lists nothing, so start from the release's notes there, `https://download.waveflow.app/server/releases//RELEASE-NOTES.md`, whose download links point at the copies. Before the copy counts, every archive and the FFmpeg sources are read back from that address and checked against `SHA256SUMS`, and the notes are read back and compared byte for byte. The archives of 2.1.0-rc.1 to 2.1.2 are already there. The code and every signed tag are also kept on a backup outside GitHub. The change is [#434](https://github.com/InstaZDLL/waveflow-server/pull/434). ## For client authors The native API gains `GET` and `PUT /api/v2/server/update`, for administrators only, answered as the other administrative routes are: `401` without a credential, `403` for an account or a token without administrative authority. Nothing else changes, and the Subsonic façade answers as it did. ## Install ```bash docker run -d --name waveflow \ -p 4533:4533 \ -v waveflow-data:/data \ -v /path/to/music:/music:ro \ ghcr.io/instazdll/waveflow-server:2.2.0 ``` The image runs on `linux/amd64` and `linux/arm64`, and is the same, digest for digest, on Docker Hub as `instazdll/waveflow-server:2.2.0`. `latest` now follows this release. The standalone archives for Windows, macOS and Linux are attached below, with `SHA256SUMS` over all of them. The same files are linked from [this release's notes on download.waveflow.app](https://download.waveflow.app/server/releases/v2.2.0/RELEASE-NOTES.md), which hold whether or not GitHub answers. ## Upgrading from 2.1.2 Pull `2.2.0` and start it on the same data volume. With an archive, use the new folder in place of the old one, carrying over what you changed in `laptop.env`: your data is kept apart from that folder. - **The database schema gains one table**, which holds the administrator's answer about the update check. Going back therefore takes a restore: `2.1.2` refuses to start on a database `2.2.0` has migrated. The boot first copies the database and its key into `pre-migration-/` in the data directory, and [`waveflow-server database restore`](https://github.com/InstaZDLL/waveflow-server/blob/v2.2.0/docs/guides/operations.md#a-copy-before-every-upgrade) puts that copy back, without anything the database gained since. With `WAVEFLOW_MIGRATION_BACKUPS=0` the boot takes no copy, and the way back is a backup of your own. - **The first administrator to sign in is asked about the update check.** Answer as you like; the choice can be changed in Settings › Administration. To decide for everyone in advance, set `WAVEFLOW_UPDATE_CHECK=on` or `off`, and nobody is asked. Coming from 2.1.1 or earlier, read the [2.1.2 notes](https://github.com/InstaZDLL/waveflow-server/blob/v2.2.0/docs/releases/v2.1.2.md) first: they are a security fix. Coming from 2.0.1 or earlier, also read the [2.1.0 notes](https://github.com/InstaZDLL/waveflow-server/blob/v2.2.0/docs/releases/v2.1.0.md#upgrading-from-201): that upgrade measures every lossless file again. **Full changelog**: [CHANGELOG.md](https://github.com/InstaZDLL/waveflow-server/blob/v2.2.0/CHANGELOG.md) · https://github.com/InstaZDLL/waveflow-server/compare/v2.1.2...v2.2.0 ## Download The server for one computer, without Docker: extract the archive and start `waveflow-server` inside it. Each archive holds the server, its own FFmpeg and a `README.txt` to read first. | System | Archive | | --- | --- | | Windows (x86_64) | [waveflow-server-2.2.0-windows-x86_64.zip](https://download.waveflow.app/server/releases/v2.2.0/waveflow-server-2.2.0-windows-x86_64.zip) | | macOS (Apple silicon) | [waveflow-server-2.2.0-macos-arm64.zip](https://download.waveflow.app/server/releases/v2.2.0/waveflow-server-2.2.0-macos-arm64.zip) | | macOS (Intel) | [waveflow-server-2.2.0-macos-x86_64.zip](https://download.waveflow.app/server/releases/v2.2.0/waveflow-server-2.2.0-macos-x86_64.zip) | | Linux (x86_64) | [waveflow-server-2.2.0-linux-x86_64.tar.gz](https://download.waveflow.app/server/releases/v2.2.0/waveflow-server-2.2.0-linux-x86_64.tar.gz) | | Linux (arm64) | [waveflow-server-2.2.0-linux-arm64.tar.gz](https://download.waveflow.app/server/releases/v2.2.0/waveflow-server-2.2.0-linux-arm64.tar.gz) | The Windows executables carry a self-signed certificate and the macOS ones an ad-hoc signature, which neither system trusts, so both warn on the first launch: `README.txt` says what to click past. [`SHA256SUMS`](https://download.waveflow.app/server/releases/v2.2.0/SHA256SUMS) holds the checksums of them all, and [`ffmpeg-8.1.3-sources.tar.gz`](https://download.waveflow.app/server/releases/v2.2.0/ffmpeg-8.1.3-sources.tar.gz) the source of the FFmpeg they carry. ## Container image ```bash docker pull ghcr.io/instazdll/waveflow-server:2.2.0 ``` The same image, digest for digest, is on Docker Hub: ```bash docker pull instazdll/waveflow-server:2.2.0 ``` Also published as `latest` in both, for `linux/amd64` and `linux/arm64` (a Raspberry Pi 4 or 5 on a 64-bit system).