Release cycle es ES

Ciclo de lanzamiento

ASF usa el versionado común de C# que es A.B.C.D. La versión se incrementa después de publicar la actual en GitHub. Cada versión publicada hasta ahora está disponible en GitHub, en estado congelado, y no desaparecerá con el tiempo, por lo tanto siempre es posible volver a cualquiera de ellas, sin necesidad de hacer copias propias.

En general, el versionado de ASF es muy simple - usamos números del 0 al 9 en lugar de A, B, C y D. El salto incrementa D, si la nueva D resultase ser el número 10, en su lugar incrementamos C y establecemos D de vuelta a 0, y así sucesivamente. La publicación de una nueva versión se supone sea tratada como un hito en ASF, una versión con una característica implementada y lista para pruebas/uso, sin causar ninguna regresión en comparación con la anterior. A veces podemos decidir que los cambios introducidos con muy importantes e incrementar C, B o incluso A, aunque eso es muy raro (y normalmente indica cambios radicales).

Las versiones de ASF se dividen en dos categorías - versiones estables y pre-versiones.

Se supone que las versiones estables funcionan correctamente y sin ninguna regresión conocida (al momento de la publicación) en comparación con las anteriores. Solemos liberar una versión estable ya sea después de un largo período de pruebas prelanzamiento, o como una versión que corrige bugs de la versión estable anterior, sin introducir nuevos. En escenario muy raro (por ejemplo, cambio radical de Steam) también podemos decidir publicar una versión estable lo más rápido posible, si es necesario. Aunque en general, esas versiones deberían funcionar bastante bien, ya que no marcamos una versión como estable si resulta en una peor condición de salud general comparada a la versión estable anterior. Por supuesto, dicha "salud general" se basa en reportes y comentarios que recibimos durante el desarrollo de las pre-versiones, por lo que lamentablemente aún es posible que algunos bugs se puedan colar y sean descubiertos después de publicar la versión estable, simplemente porque nadie lo descubrió durante la fase de desarrollo. Afortunadamente para nosotros es bastante raro que algo como esto ocurra, y solemos corregirlo tan rápido como sea posible en una versión estable de seguimiento.

Las pre-versiones son más frecuentes y generalmente introducen cambios que todavía son trabajo en proceso, sugerencias o nuevas implementaciones. No se garantiza que la preversión sea estable, aunque siempre intentamos hacer alguna pruebas antes de pasarla a GitHub, así que nunca debería ser una versión que esté completamente rota en términos de uso práctico. El punto principal de las pre-versiones es obtener comentarios de los usuarios más avanzados y descubrir bugs nuevos (si hay) antes de que lleguen a la versión estable. La calidad de ese trabajo depende en gran medida en el número de testers, bugs que se reportan en GitHub y comentarios generales.

Las pre-versiones generalmente deberían funcionar tan bien como las versiones estables, y la única diferencia entre ellas es simplemente el hecho de ser probada por más usuarios. Esto es porque ASF es un proyecto "rodante", lo que significa que debería ser posible de compilar y usar en cualquier punto dado del tiempo, y el versionado se hace para tu conveniencia - como un hito de cambios entre una versión y otra. Aún así, si decides usar pre-versiones, normalmente deberías ser un usuario un poco más avanzado, ya que las pre-versiones normalmente son trabajo en proceso de pequeños cambios en ASF, y es totalmente posible que incluso si algo parece estar funcionando bien, puede tener cosas que no necesariamente funcionan o aún no han sido probadas - seguir el desarrollo de ASF en GitHub y leer cuidadosamente los changelogs es lo mínimo que debes hacer si quieres usar pre-versiones (por tu propio bien). Además, hay momentos en los que activamente probamos algo específico, como un cambio de configuración, nuevo código reescrito para una cosa dada, o cambios centrales. Siempre lee el changelog en este caso, ya que dicha versión prelanzamiento podría ser más inestable que otras.

Por favor, ten en cuenta que las características y cambios introducidos recientemente puede 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 dada 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 la pre-versión puede contener código de trabajo en proceso que todavía no tiene una forma final, la documentación llegará en una etapa posterior del desarrollo. Lo mismo aplica al changelog general que puede no estar disponible para una pre-versión dada hasta algún tiempo después. Por lo tanto si decides usar una pre-versión entonces prepárate para revisar cambios en el repositorio de ASF de vez en cuando.

Por supuesto, la falta de documentación aplica solo para las pre-versiones - cada versión estable siempre debe tener changelog y documentación completa en la wiki al momento de su publicación.

Una versión prelanzamiento puede ser considerada estable después de algún tiempo. Esto es especialmente cierto si no se hacen cambios mientras tanto, y no tiene sentido en subir de versión solo por una versión estable. También se hace a menudo cuando la pre-versión se considera "candidato para versión estable", ya que permite a los usuarios avanzados probarla antes de que sea marcada como estable, así que el riesgo de introducir bugs es mucho menor, por lo tanto este es el patrón más común cuando se trata de versiones de ASF:

Stable 1.0 -> Pre 1.1 -> Pre 1.2 -> ... -> Pre 1.7 (RC) -> Stable 1.7 (same as Pre 1.7)

Aunque en general, las versiones de ASF se publican cuando están listas, lo que resulta en un calendario de publicaciones impredecible. Normalmente hay una pre-versión después de hacer cualquier cambio o característica importante, y una versión estable si no se encuentran bugs después de algún tiempo (unos días) desde que la pre-versión estuvo disponible. Buscamos más o menos una versión estable por mes, a menos que haya problemas críticos con los que tratar o cosas por el estilo. Las pre-versiones suceden según sea necesario cuando creemos que hay suficientes elementos que deben probarse desde el lanzamiento de la última. Dependiendo de qué tan ocupado esté el desarrollo de ASF en un momento dado, esto puede ser desde una docena de pre-versiones entre cada versión estable.

El changelog preciso que compara una versión con la otra siempre está disponible en GitHub - a través de los "commits" y cambios en el código. En la publicación solo tendemos a documentar cambios que consideramos importantes entre la última y la actual versión. Dicho changelog nunca está completo, por lo que si quieres ver todos los cambios que ocurrieron entre una versión y otra - por favor, usa GitHub para eso.

El proyecto ASF es impulsado por un proceso de integración continua y probado por dos servicios independientes - AppVeyor que prueba ASF en Windows, y Travis que prueba ASF en Linux y OS X. Se supone que cada compilación sea reproducible, por lo tanto no debería ser problema tomar la fuente (incluida en la publicación) de una versión dada y compilarla tú mismos obteniendo el mismo resultado que la disponible a través de un binario.

Como un extra, además de las versiones y pre-versiones de ASF, también puedes encontrar la última compilación automatizada de AppVeyor aquí que normalmente se compila a partir del último "commit" aún no incluido en ningún lado. Debido a la automatización y falta de pruebas, estas compilaciones NO tienen soporte de ninguna forma, y generalmente solo están disponibles para desarrolladores que necesiten tomar el más reciente "snapshot" de ASF en GitHub en forma de objeto, para que no necesiten compilarse ellos mismos. Nada garantiza que ASF en estado master funcione correctamente. En casos raros, esas compilaciones también puede usarse para verificar si un "commit" aún no publicado en efecto solucionó un problema o bug particular, sin esperar que el cambio llegue en la pre-versión. Si decide usar esas compilaciones automatizadas, asegúrate de que tienes suficiente conocimiento en términos de ASF, ya que es el "nivel" más alto de software con bugs. A menos que tengas una buena razón, normalmente ya estás en el límite siguiendo las compilaciones de prelanzamiento - las compilaciones de AppVeyor se ofrecen como un extra a las pre-versiones, principalmente para verificar si un "commit" en particular corrigió un problema en el que estemos trabajando ahora mismo. Esas compilaciones no deben utilizarse en ningún entorno de producción.