--- title: "O Immich passou a publicar release candidates. Eis como funcionam" description: "Desde a v3, o Immich publica release candidates antes de cada versão grande. O que é uma RC, como funcionam os números de versão e as tags do Docker, como testar uma em segurança e o que significa para os utilizadores da PixelUnion." url: "https://pixelunion.eu/pt/blog/2026/10/immich-release-candidates/" date: "2026-10-14" author: "Marc" categories: ["Open Source"] tags: ["Immich","Release candidates","Open Source","Self-hosting","Updates"] --- Durante a maior parte da sua vida, o Immich teve um só tipo de versão. Aparecia uma versão nova no GitHub, as pessoas descarregavam-na e os relatórios de erros chegavam nos dias seguintes. Depois, uma versão de correção resolvia os piores. Isso funciona. Também significa que a primeira vaga de utilizadores faz os testes nas suas bibliotecas reais, sem se ter inscrito para isso. Desde a v3, isso mudou. Antes de sair uma versão grande, o Immich publica agora primeiro uma ou mais release candidates. A v3.0 teve quatro em junho, antes de a versão estável chegar a 2 de julho. A v3.2 passou por três. A v3.3 teve três em menos de uma semana, entre 29 de setembro e 2 de outubro. ## O que é uma release candidate Uma release candidate, ou RC, é uma versão que os programadores consideram pronta, mas que querem que mais pessoas vejam antes de a darem como final. As funcionalidades estão concluídas. Não se acrescentam novas. O que acontece durante a fase RC é testar e corrigir erros, mais nada. Reconheces uma pelo número de versão. `v3.3.0-rc.0` é a primeira candidata à v3.3.0, `v3.3.0-rc.1` a segunda, e assim por diante. Isto segue o [versionamento semântico](https://semver.org), em que tudo o que vem depois do hífen indica uma pré-versão. Uma pré-versão conta sempre como mais antiga do que a versão a que conduz, por isso `v3.3.0-rc.2` vem antes de `v3.3.0`. Quando ninguém encontra nada grave na última candidata, o mesmo código sai como versão estável. Quem já revelou fotografias numa câmara escura conhece o padrão. Não expões primeiro a tua melhor folha de papel. Fazes uma tira de teste, verificas, ajustas e só então fazes a prova a sério. Uma RC é a tira de teste. ## Como testar uma, e o que pode correr mal Para o servidor, apontas a variável `IMMICH_VERSION` no teu ficheiro `.env` para a candidata, por exemplo `v3.3.0-rc.2`, e executas `docker compose pull && docker compose up -d`. Há também uma tag `v3-rc` que vai sendo atualizada e aponta sempre para a candidata mais recente. Para as aplicações móveis, os utilizadores de Android podem instalar o APK a partir das notas da versão ou aderir à beta no Google Play. Os utilizadores de iOS aderem através do TestFlight. Os links estão em cada [versão no GitHub](https://github.com/immich-app/immich/releases), e é também aí que os erros devem ser reportados. Agora o reverso da medalha, porque existe. Cada RC vem com o mesmo aviso: não é uma versão estável e pode conter erros ou alterações incompatíveis. Esse aviso não é uma formalidade. Uma versão nova costuma executar migrações da base de dados ao arrancar. Essas migrações só andam para a frente. O Immich não suporta voltar a uma versão anterior, por isso se uma RC estragar alguma coisa, não podes voltar à versão anterior e continuar. Restauras a partir de uma cópia de segurança ou esperas pela próxima candidata. Por isso a regra é aborrecida, e é a certa. Faz uma cópia de segurança nova da base de dados e da tua pasta de uploads antes de experimentares uma RC. Melhor ainda, testa numa segunda instância com uma cópia dos teus dados, não na biblioteca que a tua família usa todos os dias. Se não tens uma cópia de segurança a partir da qual tenhas restaurado recentemente, o nosso artigo sobre [a regra de cópias de segurança 3-2-1](/pt/blog/3-2-1-backups-immich/) é um bom ponto de partida. Se tens um computador de reserva e algum tempo, testar RC é uma das coisas mais úteis que podes fazer por um projeto de código aberto. Escrever código não é a única forma de contribuir. Um relatório de erro claro sobre uma RC resolve um problema para milhares de pessoas antes de elas o chegarem a ver. ## O que isto significa para os utilizadores da PixelUnion Nada muda na forma como usas a PixelUnion. Não corremos release candidates na tua instância. Esperamos pela versão estável e depois implementamo-la por fases, como fizemos com a v3. Recebes as novas funcionalidades depois de terem passado pela fase RC e pelas nossas próprias verificações. Acompanhamos as RC de perto. Dizem-nos cedo o que aí vem, para podermos preparar-nos e contar-te. E como mais pessoas testam antes da versão final, as versões estáveis que te chegam devem trazer menos surpresas. Isso é bom para a comunidade do auto-alojamento, e é bom para nós. Gostávamos de fazer mais do que observar. No futuro, queremos disponibilizar uma versão beta da PixelUnion. Se nos disseres que queres participar, a tua instância passa a receber as novas versões do Immich antes da versão estável, para que possas ajudar a testá-las e dar feedback rapidamente. Esse feedback volta para o projeto Immich, e é esse o objetivo. Ainda não sabemos se nem quando esta funcionalidade vai chegar. Assim que soubermos mais, vais lê-lo aqui primeiro. Se preferes deixar os testes, as cópias de segurança e as atualizações a cargo de outra pessoa, é para isso que cá estamos. [Começa grátis com a PixelUnion →](https://pixelunion.eu) Foto de capa de [Francisco Gonzalez](https://unsplash.com/photos/-jmYFZ9CQ80) no Unsplash.