¿Qué es una Release Candidate?

Una Release Candidate (RC) o candidata a lanzamiento es una versión de un programa de software que está completa en funcionalidad y se considera lista para su lanzamiento oficial, salvo que las pruebas finales revelen un fallo crítico que obligue a corregirlo. En otras palabras, una RC es la versión que se publicaría tal cual si no aparece ningún defecto bloqueante.

La idea central es el feature freeze (congelación de funcionalidades): a partir de la RC no se añaden características nuevas. Solo se aceptan correcciones de errores graves. Si una RC supera la validación sin cambios, se promociona directamente a versión estable; si requiere arreglos, se genera una nueva RC (RC2, RC3...) y el ciclo se repite.

La fase de RC es el último control de calidad antes de exponer el software al público general. Su objetivo es dar a usuarios avanzados, equipos de QA y clientes la oportunidad de validar la versión final en condiciones lo más cercanas posible a producción, reduciendo la probabilidad de que un defecto grave llegue al lanzamiento estable.

A diferencia de las fases anteriores, donde todavía se espera encontrar fallos y cambiar funcionalidades, en una RC la expectativa es que el producto ya está terminado. Cada nueva RC que se publica es una señal de que el equipo cree haber resuelto los problemas detectados en la anterior.

Durante la fase de RC se ejecutan pruebas de regresión y de aceptación para confirmar que no se han introducido defectos al cerrar la versión. Las actividades habituales incluyen:

• Pruebas de regresión: verificar que las correcciones recientes no han roto funcionalidades existentes.
• Pruebas de aceptación de usuario (UAT): validación por parte del cliente o de un grupo de usuarios representativos.
• Smoke tests sobre el artefacto final: comprobar que el paquete que se distribuirá arranca e instala correctamente.
• Validación en un entorno espejo de producción: idealmente un entorno de staging equivalente al real.

Estas pruebas forman parte del enfoque de testing dentro del ciclo de vida del software y suelen automatizarse dentro de un pipeline de CI/CD.

Las candidatas a lanzamiento se denotan habitualmente con el sufijo RC seguido de un número, como 3.0-RC1, 3.0-RC2, etc. Cada incremento indica una nueva iteración tras corregir los fallos detectados en la anterior.

En versionado semántico (SemVer), una RC se expresa como una versión de prerelease: por ejemplo 1.4.0-rc.1. Estas etiquetas tienen menor precedencia que la versión estable equivalente (1.4.0), de modo que las herramientas de dependencias no las instalan por defecto salvo que se pidan explícitamente.

La RC es una de las fases del proceso de maduración de una versión. La secuencia habitual es:

🅰️ Alpha: la primera versión completa o casi completa de un programa, normalmente con fallos conocidos y funcionalidades incompletas. Se usa para pruebas internas. Ver Alpha.

🅱️ Beta: una versión más estable que la alpha, liberada a un grupo más amplio para recoger feedback y detectar errores en uso real. Ver Beta.

🆗 RC (Release Candidate): llega después de la beta y es el paso final antes del lanzamiento oficial. Funcionalidad congelada, solo correcciones críticas.

🎯 RTM (Release to Manufacturing / Marketing): indica que la versión final está aprobada y lista para su distribución o fabricación.

Una vez validada la RC, muchos equipos no la liberan de golpe a todos los usuarios, sino que la despliegan de forma progresiva mediante un Canary Release o un Blue/Green Deployment, de modo que si algo falla en producción puedan hacer rollback con impacto mínimo. La gestión de estas fases forma parte del ALM (gestión del ciclo de vida de la aplicación) y de la cultura DevOps.

La RC actúa como una puerta de calidad explícita: separa el momento en que el software "ya tiene todo" del momento en que "se publica". Sin esta separación es fácil seguir añadiendo cambios de última hora que introducen regresiones justo antes de un lanzamiento.

Tener un proceso de RC bien definido aporta varias ventajas:

• Reduce sorpresas en producción: el código que se prueba es exactamente el que se publicará, no una variante.
• Da visibilidad a los stakeholders: un número de RC comunica de forma clara cómo de cerca está el lanzamiento.
• Disciplina el feature freeze: evita el ciclo de "una funcionalidad más" que retrasa indefinidamente la entrega.
• Facilita la trazabilidad: cada RC queda etiquetada y archivada, lo que ayuda a auditar qué se lanzó y cuándo.

¿Cuál es la diferencia entre Beta y Release Candidate?

En la fase beta todavía se esperan cambios de funcionalidad y la aparición de fallos relevantes. En una RC la funcionalidad está congelada y la expectativa es que el producto esté terminado: solo se corrigen defectos críticos. Dicho de otra forma, toda RC podría convertirse en la versión final, mientras que una beta normalmente aún no.

¿Cuántas Release Candidates suele haber?

No hay un número fijo. Si la primera RC pasa la validación sin defectos bloqueantes, puede ser la única. Si aparecen fallos, se publican RC2, RC3, etc. Un número alto de RCs suele indicar que la versión llegó a la fase final menos madura de lo previsto.

¿Una Release Candidate es estable para usar en producción?

Está pensada para validación, no como versión de producción definitiva. Los usuarios avanzados pueden probarla en entornos controlados, pero no se recomienda desplegarla como versión definitiva hasta que se promociona a estable, porque todavía podría requerir correcciones.

¿Qué relación tiene la RC con el versionado semántico?

En SemVer, una RC se etiqueta como prerelease (1.4.0-rc.1) y tiene menor precedencia que la versión estable 1.4.0. Esto permite distribuir la candidata por los canales habituales sin que se instale por defecto a quienes solo quieren versiones estables.

¿Qué pasa después de aprobar una Release Candidate?

Si supera todas las pruebas sin cambios, se promociona a versión estable y se libera. El despliegue puede hacerse de golpe o de forma gradual mediante estrategias como Canary Release o Blue/Green, siempre con un plan de rollback preparado por si surge un problema.

• Canary Release: Despliegue gradual a un subconjunto de usuarios
• Blue/Green Deployment: Dos entornos y conmutación instantánea
• Rollback: Reversión a la versión anterior
• CI/CD: Integración y entrega continua
• ALM: Gestión del ciclo de vida de la aplicación
• DevOps: Integración de desarrollo y operaciones