Plan de versiones programadas

From The Document Foundation Wiki
Jump to: navigation, search
This page is a translated version of the page ReleasePlan and the translation is 45% complete.

Other languages:
العربية • ‎dansk • ‎Deutsch • ‎English • ‎español • ‎français • ‎Bahasa Indonesia • ‎italiano • ‎日本語 • ‎português do Brasil • ‎română • ‎русский • ‎中文(简体)‎

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.
  • Time-based release trains have been shown to produce the best quality Free software. A time based release is one that does not wait for either features, or bug fixes - but is based (as purely as possible) on time. This enforces discipline in introducing fixes, gives predictability, and allows more regular releasing. It is also the case that we will necessarily release earlier, and then rapidly, incrementally bug fix releases based on the previous stable version. Thus if you have a need for the very highest quality version, it can make sense to defer a move until the first or perhaps second minor point release.
  • There are 2 branches: Fresh (the newest release) and Still (the previous release), which are intended for mainstream feature users and conservative, corporate deployments respectively.
  • As a result, users get new major version every six months with a wide range of features, fixes, and enhancements. In addition, they get many pure bugfix micro releases. The first X.Y.0 release is intended for early adopters. More conservative users are advised to wait for a later X.Y.Z bugfix release.

Note that the dates mentioned in the schedule might get shifted if there are serious technical or other problems with the release. An extra RC might be needed if the final release candidate does not fit the Release Criteria. Such problem would shift the final release by one week or even more.

Versión 7.0

Fechas básicas para la publicación de la versión inicial y las de corrección de errores
Lanzamiento Congelamiento Publicación
7.0.0 (congelamiento: 29.ª sem.) Semana 19 , may 4, 2020 - may 10, 2020 Semana 32 , ago 3, 2020 - ago 9, 2020
7.0.1 Semana 33 , ago 10, 2020 - ago 16, 2020 Semana 36 , ago 31, 2020 - sep 6, 2020
7.0.2 Semana 38 , sep 14, 2020 - sep 20, 2020 Semana 41 , oct 5, 2020 - oct 11, 2020
7.0.3 Semana 43 , oct 19, 2020 - oct 25, 2020 Semana 46 , nov 9, 2020 - nov 15, 2020
7.0.4 Semana 48 , nov 23, 2020 - nov 29, 2020 Semana 51 , dic 14, 2020 - dic 20, 2020
7.0.5 Semana 06 , feb 8, 2021 - feb 14, 2021 Semana 09 , mar 1, 2021 - mar 7, 2021
7.0.6 Semana 15 , abr 12, 2021 - abr 18, 2021 Semana 18 , may 3, 2021 - may 9, 2021
Fin del período de servicio técnico 31 de mayo de 2021

See also the detailed schedule and the release notes.

Versión 6.4

Fechas básicas para la publicación de la versión inicial y las de corrección de errores
Lanzamiento Congelamiento Publicación
6.4.0 (congelamiento: 2.ª sem.) Semana 42 , oct 14, 2019 - oct 20, 2019 Semana 05 , ene 27, 2020 - feb 2, 2020
6.4.1 Semana 06 , feb 3, 2020 - feb 9, 2020 Semana 09 , feb 24, 2020 - mar 1, 2020
6.4.2 Semana 09 , feb 24, 2020 - mar 1, 2020 Semana 12 , mar 16, 2020 - mar 22, 2020
6.4.3 Semana 13 , mar 23, 2020 - mar 29, 2020 Semana 16 , abr 13, 2020 - abr 19, 2020
6.4.4 Semana 18 , abr 27, 2020 - may 3, 2020 Semana 21 , may 18, 2020 - may 24, 2020
6.4.5 Semana 24 , jun 8, 2020 - jun 14, 2020 Semana 27 , jun 29, 2020 - jul 5, 2020
6.4.6 Semana 30 , jul 20, 2020 - jul 26, 2020 Semana 33 , ago 10, 2020 - ago 16, 2020
6.4.7 Semana 39 , sep 21, 2020 - sep 27, 2020 Semana 42 , oct 12, 2020 - oct 18, 2020
Fin del período de servicio técnico 30 de noviembre de 2020

See also the detailed schedule and the release notes.

6.3 release

Fechas básicas para la publicación de la versión inicial y las de corrección de errores
Lanzamiento Congelamiento Publicación
6.3.0 (congelamiento: 29.ª sem.) Semana 19 , may 6, 2019 - may 12, 2019 Semana 32 , ago 5, 2019 - ago 11, 2019
6.3.1 Semana 32 , ago 5, 2019 - ago 11, 2019 Semana 35 , ago 26, 2019 - sep 1, 2019
6.3.2 Semana 36 , sep 2, 2019 - sep 8, 2019 Semana 39 , sep 23, 2019 - sep 29, 2019
6.3.3 Semana 41 , oct 7, 2019 - oct 13, 2019 Semana 44 , oct 28, 2019 - nov 3, 2019
6.3.4 Semana 47 , nov 18, 2019 - nov 24, 2019 Semana 50 , dic 9, 2019 - dic 15, 2019
6.3.5 Semana 05 , ene 27, 2020 - feb 2, 2020 Semana 08 , feb 17, 2020 - feb 23, 2020
6.3.6 Semana 15 , abr 6, 2020 - abr 12, 2020 Semana 18 , abr 27, 2020 - may 3, 2020
Fin del período de servicio técnico 29 de mayo de 2020

See also the detailed schedule and the release notes.

Fechas

The release is time-based but the schedule defines calendar weeks instead of exact dates. It is because we are always a bit flexible. The release can be delayed by few days because of blocker bugs, build problems, and other technical issues.

The release consists of several beta and release candidate builds. There are needed several actions for each build. The ideal workflow looks like:

  • Monday: commit deadline; reminder is sent to devel, l10n mailing list before it happens
  • Tuesday: the tag is created on a commit that builds and passes unit-, subsequent-, and smoke-tests; tag is announced on the devel and qa mailing lists
  • Wednesday: builds are uploaded on the early pre-release site; they are announced on the devel and qa mailing lists
  • Thursday: builds are uploaded on mirrors. They are announced via many channels, e.g. mailing lists, twitter
  • Friday: builds are available via the official pre-release site

The final release is usually announced on Thursday, few days after the final release candidate is out.

Note that we are very strict about commits to the final release candidate, so full regression test is not needed. It is used as the final build when it passes the needed tests. It is just renamed on mirrors.

Calendario

The schedule is based on the following rules:

  • do the major release every six months and synchronize it (at least one month ahead) with major Linux distributions; it always comes with a wide range of features, fixes, and enhancements
  • do a pure bugfix release every month after the main release until it is good enough even for the most conservative people; do it less frequently afterwards
  • do pure bugfix releases, including security fixes, until the next release is ready for most conservative people
  • do not do two builds the same week.

The result is the following template:

Interlocking releases
Event Verano Invierno
x.y feature freeze Jun(b) Dec(b)
x.y.0 primera versión Aug(b) Feb(b)
x.y.1 versión de corr. de errores Sep(b) Mar(b)
x.y.2 versión de corr. de errores Oct(b) Apr(b)
x.y.3 versión de corr. de errores Nov(b) May(b)
x.y.4 versión de corr. de errores Dec(b) Jun(b)
x.y.5 versión de corr. de errores Feb(m) Aug(m)
x.y.6 versión de corr. de errores Apr(m) Oct(m)

Where (b) means the beginning of the month, (m) means the middle of the month and (e) means the end of the month.

Congelamiento de las cadenas

The release plans for the first version of each major release indicate a "hard English string & UI freeze". The idea is to make the lives of translators easier. The translators should be able to trust that no new translatable strings are added into the UI or Help files between the period of the string freeze and release.

After the first version of a major release is out, correcting mistakes in the UI and Help strings is fine. Any completely new content should target the next major release.

Version scheme

We do several builds around each release. The following versioning scheme is used:

  • X.Y.0.0.alphaZ - Zth alpha version of the initial release
  • X.Y.0.0.betaZ - Zth beta version of the initial release
  • X.Y.0.Z - Zth release candidate of the initial release, last rc is considered as final and put on the main download page
  • X.Y.1.Z - Zth release candidate of the 1st bugfix release, last rc is considered as final and put on the main download page

It seems to be the best compromise with the following advantages:

  • easy to understand for normal users, alpha, beta flags are known from other projects, so they set reasonable expectations
  • correct alphabetical sorting in RPM, Bugzilla
  • “easy” to parse (alpha/beta strings delimited by dot)

There was a long discussion about this scheme on the mailing list.

Aceleración del ciclo de versiones

This acceleration of the release cycle involves some considerable release engineering and QA effort. To reduce the cost of these, we work to provide complete (ie. containing all languages) daily snapshots of the master branch to allow continual testing of code improvements. This works partially already, as can be seen/downloaded from here.

Similarly, we plan to increasingly automate the build process to allow a much lower-touch release flow, and to continue to shrink the footprint of our binaries to allow far more rapid transfer of product-equivalent builds.

Versiones sin vida útil

A release normally has a lifetime of around nine months. We consider a release to have reached its End of Life (EOL) one month after the last planned release.

If you want longer term support for a release, you’re encouraged to engage any certified L3 provider who could provide you with the service.

Because of the amount of data, the releases were split out to ReleasePlan/Archive.