ReleasePlan/es

Introducción
El modelo de desarrollo por series de publicaciones periódicas ha demostrado producir el software libre de mejor calidad. Los lanzamientos periódicos son aquellos que no se detienen si no se ha terminado una funcionalidad o incluido una corrección de error; en la medida de lo posible, el tiempo es la única métrica. Esto disciplina a los desarrolladores a incluir correcciones a tiempo, proporciona previsibilidad y permite actualizar el producto constantemente. El proyecto necesita publicar, tan pronto como sea posible, versiones con mejoras incrementales basadas en la versión estable anterior. Por este motivo, puede que tenga sentido esperar a que se publique la primera o segunda actualización menor de una versión estable —p. ej., 5.0.1 o 5.0.2 son, respectivamente, la primera y segunda actualizaciones de la versión 5.0—.


 * LibreOffice produce versiones semestrales predecibles, las cuales están en perenne sincronía con otros proyectos de software libre (como GNOME) y que se emiten con al menos un mes de antelación a los lanzamientos de distribuciones Linux importantes (como Ubuntu).


 * Sincronizar la planificación de versiones con el resto del ecosistema del software libre trae grandes ventajas, dado que permite distribuir las funcionalidades recientes a los usuarios con extrema rapidez, dado que reduce el retardo en el ciclo de las distribuciones. Por este motivo buscamos crear versiones nuevas cada seis meses y alinearlas a los meses de marzo y septiembre.

También se da el caso de que necesariamente se lanzan antes, y luego rápidamente, versiones de corrección de errores incrementales basadas en la versión estable anterior. Por lo tanto, si necesita la versión con más calidad, puede tener sentido posponer una actualización hasta el primer o quizás el segundo lanzamiento de la versión punto menor.
 * Se ha demostrado que las versiones de lanzamiento basados ​​en el tiempo producen software libre de la mejor calidad. Una versión de este tipo es aquella que no espera características ni correcciones de errores, sino que se basa (tan puramente como sea posible) en el tiempo. Esto impone disciplina en la introducción de correcciones, brinda previsibilidad y permite una liberación más regular.


 * Hay dos ramas: «Fresh/Nuevo» (la versión más reciente) y «Still/Estable» (la versión inmediatamente anterior), las cuales se destinan, respectivamente, a usuarios generales que quieren probar las últimas novedades y a entornos empresariales o de producción que buscan mayor fiabilidad.


 * Como resultado, los usuarios obtienen una nueva versión principal cada seis meses con una amplia gama de funciones, correcciones y mejoras. Además, obtienen muchos micro lanzamientos de corrección de errores puros. El primer lanzamiento de X.Y.0 está destinado a los primeros usuarios. Se recomienda a los usuarios más conservadores que esperen una versión posterior de la corrección de errores de X.Y.Z.

Tenga en cuenta que las fechas mencionadas en el cronograma pueden cambiarse si hay problemas técnicos serios o de otro tipo con el lanzamiento. Es posible que se necesite un a versión candidata (RC) adicional si la versión candidata final no se ajusta a los Criterios de versión. Tal problema cambiaría el lanzamiento final por una semana o incluso más.

El gráfico simplificado siguiente muestra tres versiones colocadas en una línea de tiempo de 24 meses.

Futuro Fresh Still

Versión 7.4
Consulte también el programa detallado y el informe de novedades.

Versión 7.3
Consulte también el programa detallado y el informe de novedades.

Versión 7.2
Consulte también el programa detallado y el informe de novedades.

Versión 7.1
Consulte también el programa detallado y el informe de novedades.

Versión 7.0
Consulte también el programa detallado y las notas de la versión.

Versión 6.4
Consulte también el calendario detallado y el informe de novedades.

Versión 6.3
Consulte también el calendario detallado y las notas de la versión.

Fechas
El lanzamiento se basa en el tiempo, pero el cronograma define semanas calendario en lugar de fechas exactas. Es porque siempre somos un poco flexibles. El lanzamiento puede retrasarse unos días debido a errores de bloqueo, problemas de compilación y otros problemas técnicos.

El lanzamiento consta de varias compilaciones beta y candidatas a lanzamiento. Se necesitan varias acciones para cada compilación. El flujo de trabajo ideal se ve así:


 * Lunes: fecha límite de confirmación; se envía un recordatorio a la lista de correo desarroyo, l10n antes de que suceda
 * Martes: la etiqueta se crea en una confirmación que compila y pasa las pruebas unitarias, subsiguientes y de humo; la etiqueta se anuncia en las listas de correo de desarrollo y control de calidad
 * Miércoles: las compilaciones se cargan en el sitio de versiones preliminares; se anuncian en el las listas de correo desarrollo y control de calidad
 * Jueves: las compilaciones se cargan en espejos. Se anuncian a través de muchos canales, p. listas de correo, twitter
 * Viernes: las compilaciones están disponibles a través del sitio oficial de versiónes de desarrollo

El lanzamiento final generalmente se anuncia el jueves, pocos días después de que salga el candidato de lanzamiento final.

Tenga en cuenta que somos muy estrictos con las confirmaciones de la versión candidata final, por lo que no es necesaria una prueba de regresión completa. Se utiliza como la versión final cuando pasa las pruebas necesarias. Se acaba de renombrar en los espejos.

Agenda
La agenda en las siguientes reglas:


 * haga el lanzamiento principal cada seis meses y sincronícelo (al menos un mes antes) con las principales distribuciones de Linux; siempre viene con una amplia gama de funciones, correcciones y mejoras
 * haga un lanzamiento puro de corrección de errores cada mes después del lanzamiento principal hasta que sea lo suficientemente bueno incluso para las personas más conservadoras; hagalo posteriormente y con menos frecuencia.
 * haga lanzamientos puros de corrección de errores, incluidas las correcciones de seguridad, hasta que el próximo lanzamiento esté listo para la mayoría de las personas conservadoras
 * no haga dos compilaciones la misma semana.

El resultado es la siguiente plantilla:

Donde (i) significa el inicio del mes, (m) significa la mitad del mes y (f) significa el final del mes.

Congelamiento de las cadenas
Los planes de lanzamiento para la primera versión de cada lanzamiento principal indican una "congelación de la interfaz de usuario y la secuencia de comandos en inglés". La idea es facilitar la vida de los traductores. Los traductores deberían poder confiar en que no se agregarán nuevas cadenas traducibles a la interfaz de usuario ni a los archivos de ayuda entre el período de congelación y publicación de cadenas.

Después de que sale la primera versión de una versión principal, está bien corregir los errores en la interfaz de usuario y las cadenas de ayuda. Cualquier contenido completamente nuevo debe apuntar al próximo lanzamiento importante.

Esquema de versiones
Hacemos varias compilaciones en torno a cada versión. Se utiliza el siguiente esquema de versiones:


 * X.Y.0.0.alphaZ - Zth versión alfa de la versión inicial
 * X.Y.0.0.betaZ - Zth versión beta del lanzamiento inicial
 * X.Y.0.Z - Candidato de lanzamiento Zth del lanzamiento inicial, el último rc se considera como final y se coloca en la página principal de descarga
 * X.Y.1.Z - Candidato de lanzamiento Zth del primer lanzamiento de corrección de errores, el último rc se considera como final y se coloca en la página de descarga principal

Parece ser el mejor compromiso con las siguientes ventajas:


 * fácil de entender para los usuarios normales, las banderas alfa y beta se conocen de otros proyectos, por lo que establecen expectativas razonables
 * clasificación alfabética correcta en RPM, Bugzilla
 * "fácil" de analizar (cadenas alfa/beta delimitadas por puntos)

Hubo una larga discusión sobre este esquema en la lista de correo.

Aceleración del ciclo de versiones
Esta aceleración del ciclo de lanzamiento implica una ingeniería de lanzamiento y un esfuerzo de control de calidad considerables. Para reducir el costo de estos, trabajamos para proporcionar instantáneas diarias completas (es decir, que contengan todos los idiomas) de la rama maestra para permitir la prueba continua de las mejoras del código. Esto ya funciona parcialmente, como se puede ver/descargar desde aquí.

Del mismo modo, planeamos automatizar cada vez más el proceso de compilación para permitir un flujo de lanzamiento de mucho menor contacto y continuar reduciendo el espacio físico de nuestros binarios para permitir una transferencia mucho más rápida de compilaciones equivalentes al producto.

Versiones sin vida útil
Un lanzamiento normalmente tiene una vida útil de alrededor de nueve meses. Consideramos que un lanzamiento ha llegado a su Fin de vida (EOL) un mes después del último lanzamiento planificado.

Si desea soporte a más largo plazo para una versión, le recomendamos que contrate a cualquier | Desarrollador certificado que pueda brindarle el servicio.

Debido a la cantidad de datos, los lanzamientos se dividieron en ReleasePlan/Archive.