Release candidate (RC): qué significa y cómo gestionarlo

Una release candidate (RC) es una build que el equipo cree lista para salir. Tiene todas las funciones, ha pasado las pruebas previstas y se convierte en la versión final sin cambios, salvo que alguien encuentre un error lo bastante grave como para bloquearla. La etiqueta es una promesa sobre la build: ninguna función nueva, solo correcciones de bloqueos. Si hace falta una corrección, el equipo corta una nueva candidata y el reloj vuelve a empezar.

¿Qué es una release candidate en software?

Es la última etapa de pre-release antes de la disponibilidad general. La idea es que la build es una candidata a la versión final, y la release se hace promoviendo esa misma build en lugar de crear una nueva. El artículo de Wikipedia sobre el ciclo de vida de lanzamiento de software describe la misma secuencia de alfa, beta, release candidate y release, y los términos se entienden ampliamente en proyectos de código abierto y proveedores.

¿Cuál es la diferencia entre beta y release candidate?

Una beta todavía puede cambiar. Se pueden ajustar funciones, mover interfaces, y el objetivo es descubrir qué falta o qué está mal. Una release candidate ya no cambia de esa manera, y el objetivo es confirmar que nada bloquea la release. La prueba práctica es qué hace el equipo con un informe de error. En una beta, un informe puede llevar a un cambio de diseño. En una RC, un informe lleva a una corrección solo si el error impide salir, y todo lo demás queda en cola para la siguiente versión.

¿Cómo se versiona una release candidate?

Usa un sufijo de pre-release en la versión que vas a lanzar. Con Semantic Versioning, un guion seguido de identificadores separados por puntos marca una pre-release, así que la primera candidata para 2.4.0 es 2.4.0-rc.1, la siguiente es 2.4.0-rc.2 y la release es simplemente 2.4.0.

La precedencia sigue la especificación: 2.4.0-rc.1 ordena por debajo de 2.4.0-rc.2, y cualquier pre-release ordena por debajo de la release. Como los identificadores se comparan uno a uno y los números se comparan numéricamente, rc.10 ordena por encima de rc.9. Los nombres alpha, beta y rc también se ordenan alfabéticamente en el orden correcto, parte de la razón por la que los equipos los usan. Etiqueta cada candidata en git, como se describe en tags de git y releases, para que quede registrado el commit exacto.

¿Cuáles son los criterios de salida de una release candidate?

Escríbelos antes de cortar la primera RC. Un conjunto viable:

• La suite de pruebas automáticas pasa en el commit exacto que se construyó.
• La ruta de actualización desde la release anterior se probó con datos realistas.
• Los problemas conocidos están clasificados y ninguno se considera bloqueo.
• El rendimiento y las tasas de error coinciden con la release anterior dentro de un margen acordado.
• Las notas de versión están redactadas y revisadas frente a la lista final de cambios.
• Existe una vía de rollback y alguien la ha leído.

Cuando cada línea es cierta para una candidata, esa candidata es la release. Si alguna línea falla, la corrección produce una nueva candidata y las comprobaciones empiezan de nuevo. La versión de siete pasos de este flujo, con responsables para cada paso, está en proceso de gestión de releases.

¿Qué hacer con la build cuando una RC pasa?

Promueve el mismo artefacto. No reconstruyas desde el tag, porque una reconstrucción puede traer una dependencia o una salida del compilador distinta, y las pruebas que hiciste se aplicaron a la build original. Muchos equipos renombran la candidata con un nuevo tag o reapuntando una etiqueta del registro, de modo que los bytes probados sean los que descargan los usuarios.

En el caso de los paquetes, publica las candidatas en un canal aparte para que los usuarios normales no las reciban por accidente. Con npm, npm publish --tag rc deja la etiqueta predeterminada latest donde estaba, y solo quien pide @rc recibe la candidata. Las imágenes de contenedor y las builds móviles tienen la misma idea con otros nombres: una etiqueta de pre-release, un despliegue escalonado o un canal al estilo TestFlight.

¿Cómo se escriben las notas de versión de una release candidate?

Empieza las notas en la primera RC y mantenlas al ritmo de las candidatas. Los testers necesitan saber qué cambió, qué revisar y qué se sabe que está roto, y redactar pronto saca a la luz las entradas que nadie recuerda al final. Marca la página o la release de GitHub como pre-release para que nadie la confunda con la versión final, y pasa el texto terminado a la release GA cuando salga. El formato y el contenido están en notas de versión de software, y la parte de GitHub, en notas de release de GitHub.

¿Los equipos SaaS necesitan release candidates?

Los equipos que despliegan de forma continua rara vez las necesitan, porque el despliegue a producción es la prueba y un feature flag controla quién ve un cambio. Las release candidates se ganan su sitio cuando los usuarios instalan el software ellos mismos y no se puede revertir con un despliegue: librerías, apps de escritorio y móviles, productos autoalojados y APIs con clientes de larga vida. En un producto alojado que expone los cambios poco a poco, el equivalente es un despliegue escalonado, que el artículo sobre notas de versión con feature flags trata desde el lado de la comunicación.

FAQ

¿Qué significa RC en software? RC son las siglas de release candidate. Es una build que el equipo pretende lanzar como versión final salvo que las pruebas encuentren un error bloqueante. Sigue a las etapas alfa y beta y precede a la disponibilidad general.

¿Es una release candidate lo bastante estable para producción? Normalmente sí para probar en staging o en una producción limitada, y conlleva un riesgo que la release final no tiene, porque las pruebas pueden no haber terminado. Trátala como código de calidad de producción que sigue en periodo de prueba.

¿Cuántas release candidates debería tener una release? Las que hagan falta, y la mayoría de las releases necesitan de una a tres. Una larga serie de candidatas suele indicar que el congelamiento se declaró demasiado pronto o que la cobertura de pruebas detecta cosas tarde.

¿Puede una release candidate convertirse en la release final sin cambios? Sí, y es el resultado previsto. La release final debe ser la misma build que la última candidata, solo renombrada o reetiquetada como GA.

Las afirmaciones técnicas de este artículo no se han revisado de forma independiente. Si algo está mal, avísanos y lo corregiremos.

Relacionado en changeloop: Documentación para desarrolladores, Plantilla de release notes