O Immich passou a publicar release candidates. Eis como funcionam
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, 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, 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 é 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 →
Foto de capa de Francisco Gonzalez no Unsplash.