--- title: "Immich wydaje teraz release candidates. Oto jak działają" description: "Od v3 Immich publikuje release candidates przed każdym dużym wydaniem. Czym jest RC, jak działają numery wersji i tagi Dockera, jak bezpiecznie ją przetestować i co to oznacza dla użytkowników PixelUnion." url: "https://pixelunion.eu/pl/blog/2026/10/immich-release-candidates/" date: "2026-10-14" author: "Marc" categories: ["Open Source"] tags: ["Immich","Release candidates","Open Source","Self-hosting","Updates"] --- Przez większość swojego istnienia Immich miał jeden rodzaj wydań. Nowa wersja pojawiała się na GitHubie, ludzie ją pobierali, a w kolejnych dniach napływały zgłoszenia błędów. Potem wydanie poprawkowe naprawiało najgorsze z nich. To działa. Oznacza to jednak też, że pierwsza fala użytkowników testuje wersję na swoich prawdziwych bibliotekach, choć wcale się na to nie zgłaszała. Od v3 to się zmieniło. Zanim duże wydanie trafi do ludzi, Immich publikuje teraz najpierw jedną lub kilka release candidates. v3.0 miała ich cztery w czerwcu, zanim 2 lipca pojawiła się wersja stabilna. v3.2 przeszła przez trzy. v3.3 miała trzy w niecały tydzień, między 29 września a 2 października. ## Czym jest release candidate Release candidate, czyli RC, to wersja, którą deweloperzy uważają za gotową, ale chcą, żeby przyjrzało się jej więcej osób, zanim uznają ją za ostateczną. Funkcje są skończone. Nowe nie są już dodawane. W fazie RC odbywa się testowanie i naprawianie błędów, nic więcej. Rozpoznasz ją po numerze wersji. `v3.3.0-rc.0` to pierwsza kandydatka do v3.3.0, `v3.3.0-rc.1` druga i tak dalej. To zgodne z [wersjonowaniem semantycznym](https://semver.org), w którym wszystko po łączniku oznacza wersję przedpremierową. Wersja przedpremierowa zawsze liczy się jako starsza od wersji, do której prowadzi, więc `v3.3.0-rc.2` jest sortowana przed `v3.3.0`. Gdy nikt nie znajdzie niczego poważnego w ostatniej kandydatce, ten sam kod zostaje wydany jako wersja stabilna. Fotografowie pracujący w ciemni znają ten schemat. Nie naświetlasz najpierw najlepszego arkusza papieru. Robisz pasek próbny, sprawdzasz go, korygujesz i dopiero potem robisz właściwą odbitkę. RC to pasek próbny. ## Jak ją przetestować i co może pójść źle Na serwerze ustawiasz zmienną `IMMICH_VERSION` w pliku `.env` na kandydatkę, na przykład `v3.3.0-rc.2`, i uruchamiasz `docker compose pull && docker compose up -d`. Istnieje też ruchomy tag `v3-rc`, który zawsze wskazuje na najnowszą kandydatkę. W przypadku aplikacji mobilnych użytkownicy Androida mogą zainstalować plik APK z informacji o wydaniu albo dołączyć do bety w Google Play. Użytkownicy iOS dołączają przez TestFlight. Linki znajdziesz w każdym [wydaniu na GitHubie](https://github.com/immich-app/immich/releases) i tam też należy zgłaszać błędy. Teraz o kosztach, bo takie są. Każda RC ma to samo ostrzeżenie: nie jest wydaniem stabilnym i może zawierać błędy lub zmiany łamiące zgodność. To ostrzeżenie nie jest formalnością. Nowa wersja zwykle przy uruchomieniu wykonuje migracje bazy danych. Te migracje działają tylko w jedną stronę. Immich nie obsługuje przechodzenia na starszą wersję, więc jeśli RC coś zepsuje, nie możesz wrócić do poprzedniej wersji i działać dalej. Przywracasz dane z kopii zapasowej albo czekasz na kolejną kandydatkę. Zasada jest więc nudna i jest właściwa. Zrób świeżą kopię zapasową zarówno bazy danych, jak i folderu z przesłanymi plikami, zanim wypróbujesz RC. Jeszcze lepiej testuj na drugiej instancji z kopią swoich danych, a nie na bibliotece, z której Twoja rodzina korzysta na co dzień. Jeśli nie masz kopii zapasowej, z której niedawno udało Ci się przywrócić dane, nasz wpis o [zasadzie kopii zapasowych 3-2-1](/pl/blog/3-2-1-backups-immich/) to dobre miejsce na start. Jeśli masz wolny komputer i trochę czasu, testowanie RC to jedna z najbardziej przydatnych rzeczy, jakie możesz zrobić dla projektu open source. Pisanie kodu nie jest jedynym sposobem, by się przyczynić. Jasne zgłoszenie błędu w RC rozwiązuje problem tysięcy osób, zanim w ogóle go zobaczą. ## Co to oznacza dla użytkowników PixelUnion W tym, jak korzystasz z PixelUnion, nic się nie zmienia. Nie uruchamiamy release candidates na Twojej instancji. Czekamy na wydanie stabilne, a potem wdrażamy je etapami, tak jak zrobiliśmy to z v3. Nowe funkcje dostajesz, gdy przejdą przez fazę RC i nasze własne kontrole. Za to uważnie śledzimy kolejne RC. Wcześnie pokazują nam, co nadchodzi, więc możemy się przygotować i Ci o tym powiedzieć. A ponieważ więcej osób testuje przed ostatecznym wydaniem, wersje stabilne, które do Ciebie trafiają, powinny zawierać mniej niespodzianek. To dobre dla społeczności self-hostingu i dobre dla nas. Chcielibyśmy robić coś więcej niż tylko się przyglądać. W przyszłości chcemy uruchomić wersję beta PixelUnion. Jeśli dasz nam znać, że chcesz wziąć udział, Twoja instancja będzie otrzymywać nowe wersje Immich jeszcze przed wydaniem stabilnym, dzięki czemu będziesz mógł pomóc w testach i szybko przekazać opinię. Te opinie trafiają z powrotem do projektu Immich i właśnie o to chodzi. Nie wiemy jeszcze, czy i kiedy ta funkcja się pojawi. Gdy będziemy wiedzieć więcej, przeczytasz o tym tutaj jako pierwszy. Jeśli wolisz zostawić testowanie, kopie zapasowe i aktualizacje komuś innemu, właśnie po to jesteśmy. [Zacznij za darmo z PixelUnion →](https://pixelunion.eu) Zdjęcie na okładce: [Francisco Gonzalez](https://unsplash.com/photos/-jmYFZ9CQ80) na Unsplash.