Plan de versiones programadas

    From The Document Foundation Wiki
    This page is a translated version of the page ReleasePlan and the translation is 72% complete.

    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.
    • 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 tiene un problema catastrófico. Tal problema cambiaría el lanzamiento final por una semana o incluso más. La decisión debería tomarse en una reunión del Comité directivo de desarrollo.

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

    Futuro
    Fresh
    Still

    24.2 release

    Basic dates for the initial and bugfix releases
    Release Freeze Publishing
    24.2.0 (freeze: week 02) Semana 47 , nov 20, 2023 - nov 26, 2023 Semana 05 , ene 29, 2024 - feb 4, 2024
    24.2.1 Semana 06 , feb 5, 2024 - feb 11, 2024 Semana 09 , feb 26, 2024 - mar 3, 2024
    24.2.2 Semana 10 , mar 4, 2024 - mar 10, 2024 Semana 13 , mar 25, 2024 - mar 31, 2024
    24.2.3 Semana 15 , abr 8, 2024 - abr 14, 2024 Semana 18 , abr 29, 2024 - may 5, 2024
    24.2.4 Semana 20 , may 13, 2024 - may 19, 2024 Semana 23 , jun 3, 2024 - jun 9, 2024
    24.2.5 Semana 26 , jun 24, 2024 - jun 30, 2024 Semana 29 , jul 15, 2024 - jul 21, 2024
    24.2.6 Semana 33 , ago 12, 2024 - ago 18, 2024 Semana 36 , sep 2, 2024 - sep 8, 2024
    24.2.7 Semana 41 , oct 7, 2024 - oct 13, 2024 Semana 44 , oct 28, 2024 - nov 3, 2024
    End of Life November 30, 2024

    7.6 release

    Basic dates for the initial and bugfix releases
    Release Freeze Publishing
    7.6.0 (freeze: week 30) Semana 19 , may 8, 2023 - may 14, 2023 Semana 34 , ago 21, 2023 - ago 27, 2023
    7.6.1 Semana 34 , ago 21, 2023 - ago 27, 2023 Semana 37 , sep 11, 2023 - sep 17, 2023
    7.6.2 Semana 38 , sep 18, 2023 - sep 24, 2023 Semana 39 , sep 25, 2023 - oct 1, 2023
    7.6.3 Semana 44 , oct 30, 2023 - nov 5, 2023 Semana 47 , nov 20, 2023 - nov 26, 2023
    7.6.4 Semana 50 , dic 11, 2023 - dic 17, 2023 Semana 53 , ene 1, 2024 - ene 7, 2024
    7.6.5 Semana 05 , ene 29, 2024 - feb 4, 2024 Semana 08 , feb 19, 2024 - feb 25, 2024
    7.6.6 Semana 10 , mar 4, 2024 - mar 10, 2024 Semana 13 , mar 25, 2024 - mar 31, 2024
    7.6.7 Semana 16 , abr 15, 2024 - abr 21, 2024 Semana 19 , may 6, 2024 - may 12, 2024
    End of Life June 12, 2024

    See also the detailed schedule and the release notes.


    7.5 release

    Basic dates for the initial and bugfix releases
    Release Freeze Publishing
    7.5.0 (freeze: week 02) Semana 47 , nov 21, 2022 - nov 27, 2022 Semana 05 , ene 30, 2023 - feb 5, 2023
    7.5.1 Semana 06 , feb 6, 2023 - feb 12, 2023 Semana 09 , feb 27, 2023 - mar 5, 2023
    7.5.2 Semana 10 , mar 6, 2023 - mar 12, 2023 Semana 13 , mar 27, 2023 - abr 2, 2023
    7.5.3 Semana 15 , abr 10, 2023 - abr 16, 2023 Semana 18 , may 1, 2023 - may 7, 2023
    7.5.4 Semana 20 , may 15, 2023 - may 21, 2023 Semana 23 , jun 5, 2023 - jun 11, 2023
    7.5.5 Semana 26 , jun 26, 2023 - jul 2, 2023 Semana 29 , jul 17, 2023 - jul 23, 2023
    7.5.6 Semana 33 , ago 14, 2023 - ago 20, 2023 Semana 36 , sep 4, 2023 - sep 10, 2023
    7.5.7 Semana 38 , sep 18, 2023 - sep 24, 2023 Semana 39 , sep 25, 2023 - oct 1, 2023
    7.5.8 Semana 41 , oct 9, 2023 - oct 15, 2023 Semana 44 , oct 30, 2023 - nov 5, 2023
    End of Life November 30, 2023

    See also the detailed schedule and the release notes.

    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:

    Liberaciones de enclavamiento
    Evento Verano Invierno
    x.y congelación de funciones jun.(i) dic.(i)
    x.y.0 primera versión ag.(i) febr.(i)
    x.y.1 versión de corr. de errores sept.(i) mar.(i)
    x.y.2 versión de corr. de errores oct.(i) abr.(i)
    x.y.3 versión de corr. de errores nov.(i) my.(i)
    x.y.4 versión de corr. de errores dic.(i) jun.(i)
    x.y.5 versión de corr. de errores febr.(m) ag.(m)
    x.y.6 versión de corr. de errores abr.(m) oct.(m)

    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.

    In practice, you should keep an eye on the tagging of the first release candidate. One way to find out, if RC1 has been tagged is to visit the tag view of the LibreOffice core repository in Gerrit and input into the filter field: libreoffice-X.Y.Z. If the results do not contain any entry for libreoffice-X.Y.Z.1, RC1 has not yet been tagged and string changes can still be committed.

    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.