Community-Lösung

So funktionieren ZimaOS-App-Store-Updates: Manuelle Pflege, Stabilität, Pull Requests und App Store v2

A November 2025 thread asking why some ZimaOS App Store applications lagged upstream versions. Zima-Giorgio said store versions were manually maintained, stability mattered, availability issues were prioritized, and the team regularly reviewed pull requests. Current App Store v2 adds version/update metadata and content-hash-driven client updates but does not itself guarantee a fixed release cadence.

Updates im ZimaOS App Store wurden nicht durch eine einfache Regel wie „immer innerhalb von sieben Tagen nach dem Upstream-Release aktualisieren“ gesteuert. Im Quell-Thread vom November 2025 erklärte Zima-Giorgio, dass die App-Versionen manuell gepflegt wurden. Er erläuterte außerdem, dass Service-Anwendungen absichtlich hinter der neuesten Upstream-Version zurückbleiben können, weil Stabilität wichtig ist, während Probleme, die die Verfügbarkeit beeinträchtigen, höhere Priorität erhalten.

Der aktuelle App Store 2.0 ändert die Erstellung und Bereitstellung von App-Katalogen, führt aber nicht automatisch einen garantierten Wartungsrhythmus ein. Das v2-Protokoll unterstützt Versionsmetadaten, Aktualisierungszeitpunkte, Versionshinweise, Inhalts-Hashes und inkrementelle Client-Updates. Die Quelldefinition der App muss jedoch weiterhin von Menschen gepflegt und validiert werden.

IceWhale sagte, dass die Store-Versionen manuell gepflegt wurden

Die direkte Antwort aus der Quelle war kurz: Die Softwareversionen im App Store wurden manuell gepflegt, und Drittanbieter- oder Community-Stores konnten neuere Versionen anbieten.

Das erklärt, warum die Version im Standardkatalog von dem neuesten Tag abweichen kann, das der Entwickler der Upstream-Anwendung veröffentlicht hat.

Die neueste Version ist nicht immer die sicherste

Zima-Giorgio stellte später klar, dass bei Anwendungen vom Typ Service nicht immer garantiert werden kann, dass sie sofort mit der neuesten Version laufen. Stabilität ist Teil der Entscheidung.

Bei einem NAS kann ein übereiltes Datenbank- oder Major-Upgrade störender sein, als eine validierte Version zu verwenden, die eine Version hinter dem Upstream-Stand zurückliegt.

Probleme, die die Verfügbarkeit beeinträchtigen, erhalten höhere Priorität

IceWhale nannte Immich als Beispiel: Das App-Store-Paket wurde aktualisiert, als der ältere Server nicht mehr mit der entsprechenden mobilen App kompatibel war.

Das ist ein nützliches Wartungsprinzip: Ein Fehler, der die normale Nutzung verhindert, kann schnelleres Handeln rechtfertigen als ein Upstream-Release, das nur neue Funktionen enthält.

Pull Requests sind Teil des Wartungsprozesses

IceWhale sagte, dass das Team die Liste der PRs regelmäßig prüft und Anfragen nach Bedarf zusammenführt. Giorgio ermutigte Nutzer, PRs einzureichen oder eigene Stores zu erstellen, und bat ausdrücklich um Hilfe bei der Aktualisierung von Uptime Kuma.

Dadurch ist der App Store teilweise gemeinschaftlich organisiert und nicht ausschließlich ein geschlossener Katalog des Anbieters.

Der aktuelle App Store v2 verfügt über ein klarer definiertes Build- und Aktualisierungsprotokoll

Die aktuelle Entwicklerdokumentation von IceWhale besagt, dass der generierte v2-Store unter anderem folgende Felder enthält:

  • version;
  • update_at;
  • release_note;
  • content_hash.

Die Suche nach Client-Updates wird durch den Store-Index und den Inhalts-Hash gesteuert. Unveränderte Anwendungen werden daher übersprungen, während geänderte App-Metadaten oder Compose-Dateien inkrementell abgerufen werden können.

Siehe das aktuelle Build- und Aktualisierungsmodell des App Store v2.

Versionsmetadaten schaffen keine Wartungs-SLA

Ein Store kann jetzt bessere Versions- und Aktualisierungsinformationen bereitstellen, aber das Protokoll schreibt nicht vor, dass jede App innerhalb einer festen Anzahl von Tagen aktualisiert werden muss. Katalogrichtlinien und die Validierung von Apps bleiben menschliche Prozesse.

App-Store-Version und Docker-Image-Tag hängen zusammen, sind aber nicht identisch

Eine Compose-Datei kann ein bestimmtes Image-Tag festlegen, ein allgemeines Tag wie latest verwenden oder auf einen Stack mit mehreren unabhängigen Images verweisen. Die im Store angezeigte Version kann die Definition der verpackten App beschreiben, ohne zu garantieren, dass jedes Image innerhalb des Stacks derselben Versionsnummer folgt.

Prüfen Sie die Compose-Definition, wenn die genaue Upstream-Versionierung wichtig ist.

Bei größeren Anwendungsaktualisierungen ist besondere Vorsicht geboten

Anwendungen wie Nextcloud, Immich, Datenbanken und Plattformen für die Heimautomatisierung können Schema-Migrationen oder inkompatible Konfigurationsänderungen enthalten. Eine verzögerte Aktualisierung im App Store kann beabsichtigt sein, während die Maintainer das Verhalten der Migration validieren.

Sichern Sie die Anwendungsdaten, bevor Sie manuell auf eine Version wechseln, die über den Katalogstand hinausgeht.

Community-Stores können schneller sein, bergen aber andere Risiken

Drittanbieter-Stores veröffentlichen möglicherweise früher neuere Versionen, aber deren Validierung, Aktualisierungsrhythmus und Qualität der Zurücksetzung hängen von den jeweiligen Maintainerinnen und Maintainer ab. „Neuer als der Standard-Store“ bedeutet nicht automatisch „besser getestet“.

FAQ zu App-Store-Aktualisierungen

Hat IceWhale einen festen monatlichen Aktualisierungszyklus versprochen?

Nein. In der Quelle steht, dass die Versionen manuell gepflegt wurden und Stabilität sowie Verfügbarkeit die Priorität beeinflussten.

Können Nutzer dabei helfen, Apps im App Store zu aktualisieren?

Ja. IceWhale ermutigte ausdrücklich zu Pull Requests und Drittanbieter-Stores.

Verbessert App Store v2 die Aktualisierungsmetadaten?

Ja. Die aktuelle v2-Ausgabe unterstützt Version, Aktualisierungszeit, Versionshinweise und durch Inhalts-Hashes gesteuerte Aktualisierungsprüfungen.