Finding
Harmonia exposes its own server version through multiple public API surfaces, but those values are hand-maintained literals that have drifted far behind the package version. The OpenSubsonic response envelope and the general health endpoint both still advertise 0.1.0 while the workspace on this exact revision is 0.4.2 and the release train is already preparing 0.4.3.
The version is cheap build metadata and can be derived; maintaining public copies adds no independent information.
Verified against main 65644113e47814c87eaba14a6f322820974b8780.
Evidence
- Root
Cargo.toml declares [workspace.package] version = "0.4.2"; member crates inherit that package version.
crates/paroche/src/subsonic/types.rs:6-8 declares SERVER_VERSION: &str = "0.1.0".subsonic/types.rs:36-48 injects that stale literal into every OpenSubsonic XML and JSON response as serverVersion.crates/paroche/src/routes/system.rs:10-14 independently hardcodes {"status":"ok","version":"0.1.0"} for the health endpoint.- The current open release-please PR targets 0.4.3, demonstrating that these literals are not participating in the release mechanism.
No open issue currently owns the stale advertised server version.
Why this matters
Clients, diagnostics, compatibility reports, and support tooling reasonably interpret a server-provided version as the version of the running service. Returning 0.1.0 from a 0.4.x binary makes bug reports and protocol compatibility decisions ambiguous and turns every release into another opportunity for the public identity to drift.
This is also a pure SSOT violation: the build system already knows the fact exactly, so a second maintained literal cannot add value.
Desired correction
Derive the Harmonia implementation version from package/build metadata—e.g. the appropriate CARGO_PKG_VERSION/generated build constant—and expose that one value to all public protocol surfaces that mean "Harmonia implementation version." Keep third-party protocol versions such as OpenSubsonic API_VERSION = 1.16.1 separate; those are different facts.
Done when:
- health and OpenSubsonic advertise the version of the built Harmonia package without a hand-edited release literal;
- a package-version bump changes those responses automatically;
- protocol/spec versions remain independently named and unchanged; and
- a test compares the advertised Harmonia version with build/package metadata so
0.1.0-style drift cannot recur.
Finding
Harmonia exposes its own server version through multiple public API surfaces, but those values are hand-maintained literals that have drifted far behind the package version. The OpenSubsonic response envelope and the general health endpoint both still advertise
0.1.0while the workspace on this exact revision is0.4.2and the release train is already preparing 0.4.3.The version is cheap build metadata and can be derived; maintaining public copies adds no independent information.
Verified against
main65644113e47814c87eaba14a6f322820974b8780.Evidence
Cargo.tomldeclares[workspace.package] version = "0.4.2"; member crates inherit that package version.crates/paroche/src/subsonic/types.rs:6-8declaresSERVER_VERSION: &str = "0.1.0".subsonic/types.rs:36-48injects that stale literal into every OpenSubsonic XML and JSON response asserverVersion.crates/paroche/src/routes/system.rs:10-14independently hardcodes{"status":"ok","version":"0.1.0"}for the health endpoint.No open issue currently owns the stale advertised server version.
Why this matters
Clients, diagnostics, compatibility reports, and support tooling reasonably interpret a server-provided version as the version of the running service. Returning 0.1.0 from a 0.4.x binary makes bug reports and protocol compatibility decisions ambiguous and turns every release into another opportunity for the public identity to drift.
This is also a pure SSOT violation: the build system already knows the fact exactly, so a second maintained literal cannot add value.
Desired correction
Derive the Harmonia implementation version from package/build metadata—e.g. the appropriate
CARGO_PKG_VERSION/generated build constant—and expose that one value to all public protocol surfaces that mean "Harmonia implementation version." Keep third-party protocol versions such as OpenSubsonicAPI_VERSION = 1.16.1separate; those are different facts.Done when:
0.1.0-style drift cannot recur.