--- title: "Immich ya publica release candidates. Así funcionan" description: "Desde la v3, Immich publica release candidates antes de cada versión grande. Qué es una RC, cómo funcionan los números de versión y las etiquetas de Docker, cómo probar una con seguridad y qué significa para los usuarios de PixelUnion." url: "https://pixelunion.eu/es/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 la mayor parte de su vida, Immich tuvo un solo tipo de versión. Aparecía una versión nueva en GitHub, la gente la descargaba y los informes de errores llegaban en los días siguientes. Después, una versión de parche corregía los peores. Eso funciona. También significa que la primera oleada de usuarios hace las pruebas sobre sus bibliotecas reales, sin haberse apuntado a ello. Desde la v3, eso ha cambiado. Antes de que salga una versión grande, Immich publica primero una o varias release candidates. La v3.0 tuvo cuatro en junio, antes de que llegara la versión estable el 2 de julio. La v3.2 pasó por tres. La v3.3 tuvo tres en menos de una semana, entre el 29 de septiembre y el 2 de octubre. ## Qué es una release candidate Una release candidate, o RC, es una versión que los desarrolladores consideran lista, pero que quieren que revise más gente antes de darla por definitiva. Las funciones están terminadas. No se añade ninguna nueva. Lo que ocurre durante la fase RC es probar y corregir errores, nada más. Puedes reconocer una por el número de versión. `v3.3.0-rc.0` es la primera candidata para la v3.3.0, `v3.3.0-rc.1` la segunda, y así sucesivamente. Esto sigue el [versionado semántico](https://semver.org), en el que todo lo que va después del guion marca una versión previa. Una versión previa siempre cuenta como más antigua que la versión a la que conduce, así que `v3.3.0-rc.2` va antes que `v3.3.0`. Cuando nadie encuentra nada grave en la última candidata, el mismo código sale como versión estable. Quien haya revelado en un cuarto oscuro reconocerá el patrón. No expones primero tu mejor hoja de papel. Haces una tira de prueba, la revisas, ajustas y solo entonces haces la copia de verdad. Una RC es la tira de prueba. ## Cómo probar una y qué puede salir mal Para el servidor, apuntas la variable `IMMICH_VERSION` de tu archivo `.env` a la candidata, por ejemplo `v3.3.0-rc.2`, y ejecutas `docker compose pull && docker compose up -d`. También hay una etiqueta `v3-rc` que se actualiza y siempre apunta a la candidata más reciente. Para las apps móviles, los usuarios de Android pueden instalar el APK desde las notas de la versión o unirse a la beta en Google Play. Los usuarios de iOS se unen a través de TestFlight. Los enlaces están en cada [versión en GitHub](https://github.com/immich-app/immich/releases), y ahí es también donde hay que informar de los errores. Ahora el inconveniente, porque lo hay. Cada RC llega con la misma advertencia: no es una versión estable y puede contener errores o cambios incompatibles. Esa advertencia no es una formalidad. Una versión nueva suele ejecutar migraciones de la base de datos al arrancar. Esas migraciones solo van hacia delante. Immich no permite volver a una versión anterior, así que si una RC rompe algo, no puedes volver a la versión previa y seguir como si nada. Restauras desde una copia de seguridad o esperas a la siguiente candidata. Así que la regla es aburrida, y es la correcta. Haz una copia de seguridad reciente de la base de datos y de tu carpeta de subidas antes de probar una RC. Mejor aún, prueba en una segunda instancia con una copia de tus datos, no en la biblioteca que tu familia usa a diario. Si no tienes una copia de seguridad desde la que hayas restaurado hace poco, nuestro artículo sobre [la regla de copias de seguridad 3-2-1](/es/blog/3-2-1-backups-immich/) es un buen punto de partida. Si tienes un ordenador de reserva y algo de tiempo, probar RC es una de las cosas más útiles que puedes hacer por un proyecto de código abierto. Escribir código no es la única forma de contribuir. Un informe de error claro sobre una RC resuelve un problema para miles de personas antes de que lleguen a verlo. ## Qué significa esto para los usuarios de PixelUnion No cambia nada en cómo usas PixelUnion. No ejecutamos release candidates en tu instancia. Esperamos a la versión estable y luego la desplegamos por fases, como hicimos con la v3. Recibes las nuevas funciones cuando ya han pasado por la fase RC y por nuestras propias comprobaciones. Eso sí, seguimos las RC de cerca. Nos dicen pronto lo que viene, para que podamos prepararnos y contártelo. Y como más gente prueba antes de la versión final, las versiones estables que te llegan deberían traer menos sorpresas. Eso es bueno para la comunidad del autoalojamiento, y es bueno para nosotros. Nos gustaría hacer algo más que observar. En el futuro queremos poner en marcha una versión beta de PixelUnion. Si nos dices que quieres participar, tu instancia recibirá las nuevas versiones de Immich antes de la versión estable, para que puedas ayudar a probarlas y dar tu opinión rápidamente. Esas opiniones vuelven al proyecto Immich, que es de lo que se trata. Todavía no sabemos si esta función llegará ni cuándo. En cuanto sepamos más, lo leerás aquí primero. Si prefieres dejar las pruebas, las copias de seguridad y las actualizaciones en manos de otros, para eso estamos. [Empieza gratis con PixelUnion →](https://pixelunion.eu) Foto de portada de [Francisco Gonzalez](https://unsplash.com/photos/-jmYFZ9CQ80) en Unsplash.