Plan de versiones programadas
TDF LibreOffice en español Document Liberation Project Blogs comunitarios Weblate Nextcloud Redmine Preguntas y respuestas Donar
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 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.
- 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 febrero y agosto.
- 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 inferior muestra tres versiones colocadas en una línea de tiempo de 24 meses.
25.2 release
Release | Freeze | Publishing |
---|---|---|
25.2.0 (freeze: week 02) | Semana 47 , nov 18, 2024 - nov 24, 2024 | Semana 05 , ene 27, 2025 - feb 2, 2025 |
25.2.1 | Semana 06 , feb 3, 2025 - feb 9, 2025 | Semana 09 , feb 24, 2025 - mar 2, 2025 |
25.2.2 | Semana 10 , mar 3, 2025 - mar 9, 2025 | Semana 13 , mar 24, 2025 - mar 30, 2025 |
25.2.3 | Semana 15 , abr 7, 2025 - abr 13, 2025 | Semana 18 , abr 28, 2025 - may 4, 2025 |
25.2.4 | Semana 20 , may 12, 2025 - may 18, 2025 | Semana 23 , jun 2, 2025 - jun 8, 2025 |
25.2.5 | Semana 26 , jun 23, 2025 - jun 29, 2025 | Semana 29 , jul 14, 2025 - jul 20, 2025 |
25.2.6 | Semana 33 , ago 11, 2025 - ago 17, 2025 | Semana 36 , sep 1, 2025 - sep 7, 2025 |
25.2.7 | Semana 41 , oct 6, 2025 - oct 12, 2025 | Semana 44 , oct 27, 2025 - nov 2, 2025 |
End of Life | November 30, 2025 |
See also the detailed schedule and the release notes.
24.8 release
Release | Freeze | Publishing |
---|---|---|
{{{5}}} | Semana 30 , jul 22, 2024 - jul 28, 2024 | Semana 34 , ago 19, 2024 - ago 25, 2024 |
24.8.1 | Semana 34 , ago 19, 2024 - ago 25, 2024 | Semana 37 , sep 9, 2024 - sep 15, 2024 |
24.8.2 | Semana 38 , sep 16, 2024 - sep 22, 2024 | Semana 41 , oct 7, 2024 - oct 13, 2024 |
24.8.3 | Semana 43 , oct 21, 2024 - oct 27, 2024 | Semana 46 , nov 11, 2024 - nov 17, 2024 |
24.8.4 | Semana 48 , nov 25, 2024 - dic 1, 2024 | Semana 51 , dic 16, 2024 - dic 22, 2024 |
24.8.5 | Semana 5 , ene 27, 2025 - feb 2, 2025 | Semana 8 , feb 17, 2025 - feb 23, 2025 |
24.8.6 | Semana 10 , mar 3, 2025 - mar 9, 2025 | Semana 13 , mar 24, 2025 - mar 30, 2025 |
24.8.7 | Semana 16 , abr 14, 2025 - abr 20, 2025 | Semana 19 , may 5, 2025 - may 11, 2025 |
End of Life | June 12, 2025 |
See also the detailed schedule and the release notes.
24.2 release
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 |
See also the detailed schedule and the release notes.
7.6 release
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
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:
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.