funoteka 0.1.0 → 0.1.2

package/CHANGELOG.md

@@ -9,6 +9,37 @@ The version lives in exactly one place — `package.json`.
 
 _(nothing yet)_
 
+## [0.1.2] — 2026-09-17
+
+### Fixed
+
+- **The version the server reports is now the version it is.** `0.1.1`'s image and
+  package both answered `0.1.0` on `/health` and in every Subsonic envelope,
+  because the version lives in a constant (`SERVER_VERSION`) that a test pins to
+  `package.json` — and the bump to `0.1.1` raised the manifest and left the
+  constant behind. **That test failed, and `0.1.1` was tagged while CI was red**,
+  which is the more serious half of this: the pipeline was watching the artefacts
+  and nobody was watching the pipeline. The constant is corrected, and the release
+  job now fails when the image it pulls answers with a version other than the one
+  the release is about — a check that can fail is what would have caught it.
+- Nothing else changed: the same program as `0.1.0` and `0.1.1`, and the same
+  schema.
+
+## [0.1.1] — 2026-09-17
+
+### Fixed
+
+- **The release pipeline verifies the package from outside the checkout, and on
+  the Node the package asks for.** `npx funoteka@<version>` run in the repository
+  root resolves the bin from the project it happens to stand in — whose own name
+  is `funoteka` — and reported `funoteka: not found` about a package that
+  publishes and installs fine; and the check ran on whatever Node the runner
+  ships, while the CLI needs `node:sqlite`. **No server code changed in this
+  patch:** `0.1.0` and `0.1.1` are the same program, and the image and the package
+  of `0.1.0` are published and verified. This is the release that proves the
+  pipeline end to end, taken as a patch because a tag whose verification is red
+  is not a release.
+
 ## [0.1.0] — 2026-09-17
 
 First public release. A Subsonic-compatible server that reads whatever is on
@@ -88,14 +119,18 @@ folders happen to be laid out is not a question a client ever has to care about.
   funoteka, and the same package carries the CLI (`scan`, `serve`, `stop`, `status`).
   Node refuses to strip types from anything under `node_modules`, so the package ships
   the sources compiled once at release — the repository itself still needs no build.
+- **A published container image**: `ghcr.io/kzntsv-dev/funoteka:0.1.0` and
+  `:latest` — `linux/amd64` and `linux/arm64` in one manifest, so the main
+  install path needs no checkout.
 - Daemon mode with `status` and `stop`, a pid file that is checked against the
   OS rather than believed, and `DEPLOY.md`.
 
 ### Known limitations
 
-- **No published container image and no cross-build.** The `Dockerfile` is
-  built by the machine that runs it and comes out for that machine's
-  architecture.
+- **The `arm64` leg of the published image is built under emulation** on an
+  `amd64` machine, and the `Dockerfile` in this repository still builds on the
+  machine that runs it — the path taken where a published image is not wanted or
+  not reachable.
 - **ffmpeg is needed for one case only:** cue segments inside m4a/ALAC. Without
   it those tracks answer with error code 70 and everything else keeps working.
 - **Some Subsonic endpoints are stubs** and say so instead of inventing an

package/DEPLOY.md

@@ -60,9 +60,29 @@ node -e "console.log(require('crypto').randomBytes(32).toString('base64url'))"
 
 ## 3. Path A — Docker (main path)
 
-Works the same on a laptop, a NAS and a VDS. The image is built on the machine
-that runs it (`build: .`), so it comes out `amd64` or `arm64` to match that
-machine — there is no published image and no cross-build yet.
+Works the same on a laptop, a NAS and a VDS. There is a **published image** —
+`ghcr.io/kzntsv-dev/funoteka:0.1.2`, `linux/amd64` and `linux/arm64` in one
+manifest — and `build: .` still builds on the machine that runs it (that is the
+path where a published image is not wanted or not reachable).
+
+With no checkout to build from, the image and four values are the whole
+installation (verified by running exactly this against the published image):
+
+```sh
+MUSIC=/absolute/path/to/your/music
+docker run -d --name funoteka -p 4533:4533 -p 4534:4534 \
+  -e FUNOTEKA_USER=you -e FUNOTEKA_PASSWORD=change-me \
+  -e FUNOTEKA_ADMIN_TOKEN=<the token you generated> \
+  -e FUNOTEKA_SUPERVISED=1 -e FUNOTEKA_LOG_FILE=/data/funoteka.log \
+  -v "$MUSIC":/music:ro -v funoteka-data:/data \
+  --restart unless-stopped ghcr.io/kzntsv-dev/funoteka:0.1.2
+```
+
+`FUNOTEKA_SUPERVISED=1` is what makes `POST /restart` a restart rather than a
+stop, and the restart policy beside it is what supervises the process. The first
+scan is still a command, not a startup side effect — see the end of this section.
+
+From a checkout, the same installation is the compose file:
 
 ```sh
 git clone <this repository> funoteka

package/README.md

@@ -125,8 +125,8 @@ classification and you edit that layer, not your music.
   and the music reaches you through the Subsonic client you already like.
 - **Not tag-driven.** It will not merge your pressings, rename your artists to match an online
   database, or call home. Nothing about your collection leaves the machine.
-- **Not overclaiming.** Where a thing does not exist yet — a published cross-build, say — the docs
-  say so instead of pretending.
+- **Not overclaiming.** Where a thing does not exist yet — a Subsonic endpoint that is still a
+  stub, the `arm64` leg built under emulation — the docs say so instead of pretending.
 
 ## Documentation
 

package/dist/api/envelope.js

@@ -30,7 +30,7 @@ export const API_VERSION = '1.16.1';
  * module every route depends on.
  */
 export const SERVER_TYPE = 'funoteka';
-export const SERVER_VERSION = '0.1.0';
+export const SERVER_VERSION = '0.1.2';
 /**
  * The fields every answer carries, whatever the answer is.
  *

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "funoteka",
-  "version": "0.1.0",
+  "version": "0.1.2",
   "description": "Subsonic-compatible server: smart music library — scanner-classifier, cue splitting, meta layer, virtual tree",
   "license": "MIT",
   "type": "module",