The problem
templates/stemdeck.xml pins:
<Repository>ghcr.io/stemdeckapp/stemdeck:0.15.1</Repository>
0.15.2 has been published and promoted. Community Applications serves whatever is on main, so every Unraid install is on the previous release and stays there until this is changed by hand.
What it costs, and what it does not
Being honest about the size of this: for a container, 0.15.1 and 0.15.2 are almost the same software. The only change between them that reaches Docker is one extra field in the /api/health payload. The rest of 0.15.2 is the desktop shell in Rust, which containers never ship.
So nobody on Unraid is missing a fix today. The cost is version identity, which is the same reason #453 existed. When an Unraid user reports a bug they report the version the template gave them, and if that is routinely a release behind, every report needs translating before it can be acted on. The gap also compounds: the longer the pin lags, the more a catch-up bump changes at once, and the less any single one of them has been observed in the container path.
Constraints for a fix
- The image has to exist before this merges. Community Applications serves the template from
main live, so a pin to a tag that was never published is an immediate pull failure for every Unraid user.
Docker Publish runs on release: published, not on the tag, so a tag existing is not evidence the image does.- The file is XML that Unraid parses. A malformed edit does not fail loudly here, it fails on someone else's server.
The problem
templates/stemdeck.xmlpins:0.15.2 has been published and promoted. Community Applications serves whatever is on
main, so every Unraid install is on the previous release and stays there until this is changed by hand.What it costs, and what it does not
Being honest about the size of this: for a container, 0.15.1 and 0.15.2 are almost the same software. The only change between them that reaches Docker is one extra field in the
/api/healthpayload. The rest of 0.15.2 is the desktop shell in Rust, which containers never ship.So nobody on Unraid is missing a fix today. The cost is version identity, which is the same reason #453 existed. When an Unraid user reports a bug they report the version the template gave them, and if that is routinely a release behind, every report needs translating before it can be acted on. The gap also compounds: the longer the pin lags, the more a catch-up bump changes at once, and the less any single one of them has been observed in the container path.
Constraints for a fix
mainlive, so a pin to a tag that was never published is an immediate pull failure for every Unraid user.Docker Publishruns onrelease: published, not on the tag, so a tag existing is not evidence the image does.