guides

Una release candidate no es una beta con un nombre más serio. Es una afirmación concreta: esta es la versión que pensamos publicar y, salvo que alguien encuentre un problema bloqueante, se convierte en la versión final sin más cambios. En algunos proyectos la RC y la versión publicada son los mismos bytes con otra etiqueta.

Qué afirma realmente la etiqueta

Esa afirmación es lo que hace útil la etiqueta, y también lo que la hace fácil de malinterpretar. Una RC no significa que el software no tenga fallos. Significa que el equipo ha dejado de añadir cosas y ya no conoce ningún motivo para no publicar.

De ahí salen dos consecuencias. La primera es que una RC es el último momento en que informar de un problema todavía cambia el resultado, y por eso justamente los fabricantes las publican. La segunda es que un número de RC que sube es una señal en sí misma: si ves rc.4, tres candidatas anteriores fueron rechazadas y la publicación está menos asentada de lo que la palabra sugiere.

Conviene saber además que el término es una convención y no una norma. Nada obliga a lo que un fabricante entienda por ello. Algunos publican una RC que pasa a disponibilidad general sin cambios; otros siguen parcheando después de que aparezca la etiqueta. La palabra por sí sola no garantiza nada, y las notas de versión del propio proyecto son lo único que lo aclara.

Alpha, beta, rc: una escalera de completitud

La escalera que lleva hasta ella es una escalera de completitud, no de calidad, y esa distinción es la que se entiende mal.

• alpha - incompleta, las interfaces aún pueden cambiar, se esperan roturas
• beta - completa en funciones, todavía se están encontrando defectos
• rc - no se conoce ningún bloqueante, sale tal cual si no aparece nada nuevo

Una **alpha** está incompleta. Faltan funciones, las interfaces todavía cambiarán y las roturas se esperan más que se reportan. Una **beta** está completa en funciones: todo lo que estará en la versión publicada ya está, y queda averiguar qué falla. Una **release candidate** añade una afirmación más, la de que no se conoce ningún bloqueante. Las tres etapas se diferencian en lo que está terminado, no en el cuidado con que se escribió:

Cómo ordena SemVer una preversión

El versionado semántico codifica exactamente ese orden, y leerlo al pie de la letra responde a casi todas las preguntas. Los identificadores de preversión cuelgan de la versión con un guion, y una preversión siempre se ordena **antes** de la versión a la que pertenece: 1.2.0-rc.1 va antes que 1.2.0.

Dentro de la parte de preversión, los identificadores separados por puntos se comparan uno a uno. Los numéricos se comparan numéricamente y quedan por debajo de los alfanuméricos, y por eso 1.2.0-alpha.1 precede a 1.2.0-alpha.beta, y rc.2 solo sigue correctamente a rc.10 si recuerdas que son números. Nuestro artículo sobre [versionado semántico](/es/articles/que-es-el-versionado-semantico) cubre el resto de la gramática.

Tu gestor de paquetes no cogerá una por accidente

Aquí está la parte práctica que sorprende, y es una protección más que un defecto. Un rango de versiones normal **no** coincide con una preversión. Si tu manifiesto pide ^1.2.0, no cogerá 1.3.0-rc.1 aunque el número sea mayor. Hay que nombrar la preversión explícitamente, o usar un rango que ya contenga una con los mismos mayor, menor y parche.

Esa regla es lo que impide que una RC aterrice en tu build por accidente, y también lo que convierte probar una en un acto deliberado: la fijas, a propósito, en un entorno donde puedes asumir la respuesta.

Qué hacer con una

De ahí el consejo honesto. Ejecuta las release candidates en integración continua y en una máquina de preproducción, no en producción, salvo que la RC contenga una corrección que necesites en concreto y hayas aceptado lo que cuesta. Si ejecutas una, informa de lo que encuentres, porque ese es todo el sentido del ejercicio y la ventana se cierra al publicar. Y lee el [changelog](/es/articles/que-es-un-changelog) entre la última RC y la versión final: si está vacío, la candidata que probaste es la versión que vas a recibir, y es la mejor noticia que este proceso puede dar. Para sistemas de larga vida en los que prefieres no estar cerca del borde, la [vía LTS](/es/articles/que-es-una-version-lts) existe justamente para evitar esta decisión.