Release cycle es ES

Ciclo de lanzamiento

ASF utiliza el versionado común de C# con 4 números, representado como A.B.C.D. Una versión determinada siempre está "congelada", apuntando a un código fuente fijo desde el que se compiló (empaquetado junto con la versión). No pretendemos eliminar ninguna versión previamente publicada, siempre y cuando nuestro proveedor de alojamiento (GitHub) las conserve por tiempo indefinido, por lo tanto puedes regresar a cualquiera de ellas sin necesidad de hacer copias.

En general, en lo que respecta al versionado de ASF, hacemos todo lo posible por seguir el versionado semver de MAJOR.MINOR.PATCH en los 3 números menos significativos - B.C.D. Estos tres números están directamente relacionados con el código de ASF. El número A más significativo indica cambios con un alcance que va más allá del código base de ASF, normalmente afectando la infraestructura del programa.

ASF es un proyecto que apunta a tener más o menos una versión por mes, indicado por un aumento del número C. Para hacer posible esta versión, tenemos prelanzamientos más pequeños dedicados a usuarios avanzados, que sirven como marcas menores que son lanzadas según sea necesario cuando haya suficientes cambios en los que concentrarse desde la versión anterior. Finalmente, cuando se determine que un prelanzamiento es lo suficientemente estable y maduro sin regresiones críticas que deban ser corregidas en comparación con la versión estable anterior, será ascendido a la nueva versión estable, iniciando al mismo tiempo un nuevo ciclo mensual para la siguiente.

Aunque hacemos todo lo posible para asegurar que incluso nuestros prelanzamientos sean relativamente estables, debe tenerse en cuenta que los prelanzamientos deben ser evaluados cuidadosamente al ejecutarlos en un entorno de producción. Los prelanzamientos podrían tener errores críticos y funcionalidades arruinadas, que es exactamente la razón por la que los lanzamos en primer lugar - para poder evitar todo ese problema en nuestras versiones estables y ofrecer un software confiable. Si no estás dispuesto a aceptar el riesgo que proviene de usar un software potencialmente inestable, por favor, evita usar nuestras compilaciones de prelanzamiento y conserva la última versión estable, que es más apropiado para la mayoría de usuarios.

Dependiendo de la cantidad de cambios en el ciclo, normalmente solo habrá un salto de versión C (desde la versión estable anterior), y saltos en D por cada prelanzamiento según sea necesario. Sin embargo, al introducir cambios con un alcance mucho mayor, especialmente cambios importantes, el ciclo podría comenzar (o cambiar a la mitad) en el incremento de B o incluso en el A - dicho cambio indica que el ciclo de lanzamiento actual tiene el potencial de ser más inestable de lo normal, y debe ser probado con cuidado. Ten en cuenta que los cambios semver que hacemos solo se relacionan con la versión estable previamente publicada, no rastreamos el versionado entre prelanzamientos en un ciclo, lo que significa que la versión 1.0.1.2 podría tener una nueva característica que 1.0.1.1 no tenía, siempre que la versión estable previa sea de la familia 1.0.0.X. Del mismo modo, podría haber cambios mayores incluso entre dos prelanzamientos del mismo ciclo, lo que es especialmente cierto cuando todavía estamos decidiendo la forma final de una funcionalidad recién introducida o algo similar.

Salto de versión	Semver	Ejemplo de cambios
A		Cambios mayores en .NET runtime, cambios en la infraestructura, cambios importantes que están más allá del código base de ASF, cosas que podrían comerse a tu gato.
B	Major	Cambios menores en .NET runtime, cambios mayores en el código base de ASF, ediciones importantes de código que no se clasifican como menores
C	Minor	Nuevos ciclos mensuales, normalmente introduciendo nuevas funcionalidades, comandos, propiedades de configuración u otros cambios que no alteran las configuraciones existentes
D	Patch	Nuevos prelanzamientos que son parte del ciclo existente (indicado por un número más significativo), importantes correcciones de errores a las versiones estables existentes que no introducen cambios en el código más allá de lo necesario

Por favor, ten en cuenta que las características y cambios introducidos recientemente pueden no estar documentados (por ejemplo, en la wiki) hasta algún tiempo después, ya que la documentación normalmente se escribe una vez que el código para una función determinada está listo (para ahorrarnos tiempo en reescribir documentación cada vez que decidimos modificar la función en la que estamos trabajando). Debido a que los prelanzamientos pueden contener código aún en proceso que todavía no tiene una forma final, la documentación puede llegar en una etapa posterior del desarrollo. Lo mismo aplica al registro de cambios general que puede estar no disponible para un prelanzamiento determinado hasta algún tiempo después. Por lo tanto si decides usar versiones en prelanzamiento entonces prepárate para revisar los commits de ASF de vez en cuando. Por supuesto, la falta de documentación aplica solo para los prelanzamientos - cada versión estable siempre debe tener un registro de cambios y documentación completa en la wiki al momento de su publicación.

El registro de cambios preciso que compara una versión con otra siempre está disponible en GitHub - a través de los commits y cambios de código. En el lanzamiento solo tendemos a documentar cambios que consideramos importantes entre la última versión estable y el lanzamiento actual. Dicho registro de cambios nunca está completo, por lo que si quieres ver todos los cambios que ocurrieron entre una versión y otra (como las actualizaciones de nuestras dependencias) - por favor, usa la comparación de GitHub.

El proyecto ASF usa nuestro proceso de integración continua. Todas las compilaciones deben ser reproducibles, por lo tanto no debería ser problema tomar el código fuente (incluido en el lanzamiento) de una versión determinada y compilarlo tú mismo obteniendo el mismo resultado que el disponible a través de nuestros ejecutables precompilados. Normalmente evitamos compilar versiones nosotros mismos, siempre y cuando los sistemas estén funcionando, los binarios publicados provienen directamente de nuestro proceso de integración continua.