Aktualizacje Sklepu z aplikacjami ZimaOS nie były zarządzane na podstawie prostej zasady, takiej jak „zawsze aktualizuj w ciągu siedmiu dni od wydania przez upstream”. W wątku źródłowym z listopada 2025 roku Zima-Giorgio powiedział, że wersje aplikacji były utrzymywane ręcznie. Wyjaśnił również, że aplikacje usługowe mogą celowo pozostawać w tyle za najnowszym wydaniem upstream, ponieważ stabilność ma znaczenie, a problemy uniemożliwiające korzystanie z usługi otrzymują wyższy priorytet.
Obecna wersja Sklepu z aplikacjami 2.0 zmienia sposób tworzenia i dostarczania katalogów aplikacji, ale nie wprowadza automatycznie gwarantowanego harmonogramu utrzymania. Protokół v2 obsługuje metadane wersji, znaczniki czasu aktualizacji, informacje o wydaniu, skróty zawartości oraz przyrostowe aktualizacje po stronie klienta; ktoś nadal musi ręcznie utrzymywać i weryfikować definicję aplikacji źródłowej.
IceWhale powiedziało, że wersje w sklepie były utrzymywane ręcznie
Bezpośrednia odpowiedź źródłowa była krótka: wersje oprogramowania w Sklepie z aplikacjami były utrzymywane ręcznie, a sklepy zewnętrzne lub społecznościowe mogły udostępniać nowsze wersje.
Wyjaśnia to, dlaczego wersja w domyślnym katalogu może różnić się od najnowszego tagu opublikowanego przez twórcę aplikacji upstream.
Najnowsza wersja nie zawsze jest najbezpieczniejsza
Zima-Giorgio doprecyzował później, że nie zawsze można zagwarantować natychmiastowe działanie aplikacji usługowych w najnowszej wersji. Stabilność jest jednym z czynników branych pod uwagę.
W przypadku serwera NAS pośpieszna aktualizacja bazy danych lub przejście na nową główną wersję może spowodować więcej problemów niż korzystanie z jednej, zweryfikowanej wersji opóźnionej względem upstream.
Problemy uniemożliwiające korzystanie z usługi otrzymują wyższy priorytet
IceWhale podało Immich jako przykład: pakiet w Sklepie z aplikacjami został zaktualizowany, gdy starsza wersja serwera przestała być zgodna z odpowiadającą jej aplikacją mobilną.
To przydatna zasada utrzymania — awaria uniemożliwiająca normalne korzystanie z aplikacji może uzasadniać szybszą reakcję niż wydanie upstream zawierające wyłącznie nowe funkcje.
Pull requesty są częścią procesu utrzymania
IceWhale powiedziało, że zespół regularnie sprawdza listę PR-ów i w razie potrzeby scala zgłoszenia. Giorgio zachęcał użytkowników do przesyłania PR-ów lub tworzenia własnych sklepów, a także konkretnie poprosił o pomoc w aktualizacji Uptime Kuma.
Oznacza to, że Sklep z aplikacjami jest częściowo tworzony we współpracy ze społecznością, a nie wyłącznie zamkniętym katalogiem dostawcy.
Obecny Sklep z aplikacjami v2 ma bardziej precyzyjny protokół kompilowania i aktualizowania
Aktualna dokumentacja deweloperska IceWhale mówi, że wygenerowany sklep v2 zawiera między innymi następujące pola:
-
version; -
update_at; -
release_note; -
content_hash.
Sprawdzanie aktualizacji przez klienta odbywa się na podstawie indeksu sklepu i skrótu zawartości, dzięki czemu niezmienione aplikacje są pomijane, a zmienione metadane aplikacji lub pliki Compose mogą być pobierane przyrostowo.
Zobacz aktualny model kompilowania i aktualizowania Sklepu z aplikacjami v2.
Metadane wersji nie tworzą umowy SLA dotyczącej utrzymania
Sklep może teraz udostępniać dokładniejsze informacje o wersji i aktualizacji, ale protokół nie mówi, że każda aplikacja musi zostać zaktualizowana w określonej liczbie dni. Zasady katalogu i weryfikacja aplikacji nadal pozostają procesami wykonywanymi przez ludzi.
Wersja aplikacji w Sklepie z aplikacjami i tag obrazu Docker są powiązane, ale nie są identyczne
Plik Compose może przypinać konkretny tag obrazu, używać szerokiego tagu, takiego jak latest, lub odwoływać się do stosu wielu usług z kilkoma niezależnymi obrazami. Wyświetlana wersja sklepu może opisywać spakowaną definicję aplikacji, nie gwarantując, że każdy obraz w stosie ma ten sam numer wersji.
Jeśli dokładne wersjonowanie upstream ma znaczenie, sprawdź definicję Compose.
Duże aktualizacje aplikacji wymagają dodatkowej ostrożności
Aplikacje takie jak Nextcloud, Immich, bazy danych i platformy automatyki domowej mogą zawierać migracje schematu lub zmiany konfiguracji powodujące niezgodność. Opóźnienie aktualizacji w Sklepie z aplikacjami może być celowe, dopóki opiekunowie nie zweryfikują działania migracji.
Przed ręcznym przejściem do wersji nowszej niż dostępna w katalogu wykonaj kopię zapasową danych aplikacji.
Sklepy społecznościowe mogą działać szybciej, ale wiąże się to z innym ryzykiem
Sklepy zewnętrzne mogą wcześniej publikować nowsze wersje, ale ich poziom weryfikacji, częstotliwość aktualizacji i jakość mechanizmów wycofywania zależą od ich opiekunów. „Nowsza niż w sklepie domyślnym” nie oznacza automatycznie „lepiej przetestowana”.
Często zadawane pytania dotyczące aktualizacji Sklepu z aplikacjami
Czy IceWhale obiecało stały comiesięczny cykl aktualizacji?
Nie. Źródło mówi, że wersje były utrzymywane ręcznie, a priorytet zależał między innymi od stabilności i dostępności.
Czy użytkownicy mogą pomóc w aktualizowaniu aplikacji w Sklepie z aplikacjami?
Tak. IceWhale wyraźnie zachęcało do przesyłania pull requestów i tworzenia sklepów zewnętrznych.
Czy Sklep z aplikacjami v2 usprawnia metadane aktualizacji?
Tak. Obecny format v2 obsługuje wersję, czas aktualizacji, informacje o wydaniu oraz sprawdzanie aktualizacji na podstawie skrótu zawartości.
