Plan de Version
TDF LibreOffice Document Liberation Project Blogs communautaires Weblate Nextcloud Redmine Ask LibreOffice Donner
Introduction
La sortie de nouvelles versions à date fixe permet de produire des logiciels libres de meilleure qualité. Une sortie à date fixe n'attend pas de nouvelles fonctionnalités, ni de corrections de bogues, mais se produit (autant que possible) à une date fixe. Cela renforce la rigueur dans l'intégration des corrections, donne de la visibilité au projet, et permet un rythme de sortie plus régulier. Il en découle également que les mises à jour mineures de corrections de bogues, basées sur la dernière version stable, sortiront plus vite. Par conséquent, si vous recherchez la version de la plus haute qualité possible, il est préférable d'attendre la première ou la deuxième mise à jour mineure avant de changer de version.
LibreOffice publie des versions semestrielles prévisibles qui sont coordonnées avec d'autres projets de logiciels libres (par exemple Gnome) et qui ont au moins un mois d'avance sur les versions majeures des distributions Linux.
La synchronisation du calendrier de diffusion avec l'écosystème du logiciel libre présente également d'énormes avantages, car elle permet de mettre nos nouvelles fonctionnalités à la disposition des utilisateurs le plus rapidement possible - avec un minimum de décalage dans le cycle de distribution. En conséquence, nous visons des versions semestrielles, et au fil du temps, nous les poussons pour qu'elles s'alignent autant que possible sur les normes de mars/septembre.
Il y a deux branches : Fresh* (la dernière version) et Still** (la version majeure précédente), qui sont respectivement destinées aux utilisateurs de fonctionnalités grand public (qui peuvent accepter des bugs mineurs) et aux déploiements conservateurs des entreprises (qui doivent avoir une version la plus stable possible). [Note du traducteur : *Fresh et **Still sont à comprendre (traduits) dans le sens de "nouveau" et "apaisé".]
En conséquence, les utilisateurs reçoivent une nouvelle version majeure tous les six mois avec un large éventail de fonctionnalités, de corrections et d'améliorations. En outre, ils reçoivent de nombreuses micro versions de correction de bogues. La première version X.Y.0 est destinée aux utilisateurs précoces. Il est conseillé aux utilisateurs plus conservateurs d'attendre une version X.Y.Z. déboguée ultérieure.
Notez que les dates mentionnées dans le calendrier peuvent être décalées en cas de sérieux problèmes techniques ou autres problèmes liés à la diffusion. Une version RC (Release Candidate) supplémentaire peut être nécessaire si le candidat final à la libération ne correspond pas aux Critères de publication. Un tel problème décalerait la version finale d'une semaine, voire plus.
Le graphique simplifié ci-dessous montre trois versions placées sur une chronologie de 24 mois.
24.2 release
| Release | Freeze | Publishing |
|---|---|---|
| 24.2.0 (freeze: week 02) | Week 47 , nov. 20, 2023 - nov. 26, 2023 | Week 05 , janv. 29, 2024 - fév. 4, 2024 |
| 24.2.1 | Week 06 , fév. 5, 2024 - fév. 11, 2024 | Week 09 , fév. 26, 2024 - mars 3, 2024 |
| 24.2.2 | Week 10 , mars 4, 2024 - mars 10, 2024 | Week 13 , mars 25, 2024 - mars 31, 2024 |
| 24.2.3 | Week 15 , avr. 8, 2024 - avr. 14, 2024 | Week 18 , avr. 29, 2024 - mai 5, 2024 |
| 24.2.4 | Week 20 , mai 13, 2024 - mai 19, 2024 | Week 23 , juin 3, 2024 - juin 9, 2024 |
| 24.2.5 | Week 26 , juin 24, 2024 - juin 30, 2024 | Week 29 , juill. 15, 2024 - juill. 21, 2024 |
| 24.2.6 | Week 33 , août 12, 2024 - août 18, 2024 | Week 36 , sept. 2, 2024 - sept. 8, 2024 |
| 24.2.7 | Week 41 , oct. 7, 2024 - oct. 13, 2024 | Week 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) | Week 19 , mai 8, 2023 - mai 14, 2023 | Week 34 , août 21, 2023 - août 27, 2023 |
| 7.6.1 | Week 34 , août 21, 2023 - août 27, 2023 | Week 37 , sept. 11, 2023 - sept. 17, 2023 |
| 7.6.2 | Week 38 , sept. 18, 2023 - sept. 24, 2023 | Week 39 , sept. 25, 2023 - oct. 1, 2023 |
| 7.6.3 | Week 44 , oct. 30, 2023 - nov. 5, 2023 | Week 47 , nov. 20, 2023 - nov. 26, 2023 |
| 7.6.4 | Week 50 , déc. 11, 2023 - déc. 17, 2023 | Week 53 , janv. 1, 2024 - janv. 7, 2024 |
| 7.6.5 | Week 05 , janv. 29, 2024 - fév. 4, 2024 | Week 08 , fév. 19, 2024 - fév. 25, 2024 |
| 7.6.6 | Week 10 , mars 4, 2024 - mars 10, 2024 | Week 13 , mars 25, 2024 - mars 31, 2024 |
| 7.6.7 | Week 16 , avr. 15, 2024 - avr. 21, 2024 | Week 19 , mai 6, 2024 - mai 12, 2024 |
| End of Life | June 12, 2024 | |
See also the detailed schedule and the release notes.
Version 7.5
| Version | Gel | Publication |
|---|---|---|
| 7.5.0 (gel : semaine 02) | Week 47 , nov. 21, 2022 - nov. 27, 2022 | Week 05 , janv. 30, 2023 - fév. 5, 2023 |
| 7.5.1 | Week 06 , fév. 6, 2023 - fév. 12, 2023 | Week 09 , fév. 27, 2023 - mars 5, 2023 |
| 7.5.2 | Week 10 , mars 6, 2023 - mars 12, 2023 | Week 13 , mars 27, 2023 - avr. 2, 2023 |
| 7.5.3 | Week 15 , avr. 10, 2023 - avr. 16, 2023 | Week 18 , mai 1, 2023 - mai 7, 2023 |
| 7.5.4 | Week 20 , mai 15, 2023 - mai 21, 2023 | Week 23 , juin 5, 2023 - juin 11, 2023 |
| 7.5.5 | Week 26 , juin 26, 2023 - juill. 2, 2023 | Week 29 , juill. 17, 2023 - juill. 23, 2023 |
| 7.5.6 | Week 33 , août 14, 2023 - août 20, 2023 | Week 36 , sept. 4, 2023 - sept. 10, 2023 |
| 7.5.7 | Week 38 , sept. 18, 2023 - sept. 24, 2023 | Week 39 , sept. 25, 2023 - oct. 1, 2023 |
| 7.5.8 | Week 41 , oct. 9, 2023 - oct. 15, 2023 | Week 44 , oct. 30, 2023 - nov. 5, 2023 |
| Fin de vie | 30 novembre 2023 | |
Jetez aussi un œil sur le calendrier détaillé et les notes de version.
Dates
La publication est basée sur le temps, mais le calendrier définit des semaines calendaires plutôt que des dates exactes. C'est parce que nous sommes toujours un peu flexibles : la publication peut être retardée de quelques jours en raison de bogues bloquants, de problèmes de construction et d'autres problèmes techniques.
La version se compose de plusieurs versions bêta et release candidate. Plusieurs actions sont nécessaires pour chaque version. Le workflow idéal ressemble à ceci :
- Lundi : date limite de livraison ; un rappel est envoyé à devel* et à la liste de diffusion l10n** avant que cela ne se produise.
- Mardi : le tag est créé sur un commit qui construit et passe les tests unit-, subsequent-, et smoke- ; le tag est annoncé sur les mailing lists devel et qa***.
- Mercredi : les builds sont téléchargés sur le site des early pre-release ; elles sont annoncées sur les listes de diffusion devel et qa.
[Note du traducteur : *devel : développeurs, **l10n : traductions, ***qa : assurance qualité]
- Jeudi : les builds sont téléchargées sur les miroirs. Elles sont annoncées via de nombreux canaux, par exemple les listes de diffusion, twitter...
- Vendredi : les builds sont disponibles via le site officiel des pre-releases
La version finale est généralement annoncée le jeudi, quelques jours après la sortie de la version finale candidate.
Notez que nous sommes très stricts sur les commits de la version finale candidate, donc un test de régression complet n'est pas nécessaire. Elle est utilisée comme version finale lorsqu'elle passe les tests nécessaires. Elle est simplement renommée sur les miroirs.
Calendrier
Le calendrier est basé sur les règles suivantes :
- faire une version majeure tous les six mois et la synchroniser (au moins un mois à l'avance) avec les principales distributions Linux ; elle est toujours accompagnée d'un large éventail de fonctionnalités, de correctifs et d'améliorations
- faire une version de correction de bogues tous les mois après la version principale jusqu'à ce qu'elle soit suffisamment bonne, même pour les personnes les plus conservatrices ; la faire moins fréquemment par la suite
- ne faire que des versions de correction de bogues, y compris des correctifs de sécurité, jusqu'à ce que la prochaine version soit prête pour la plupart des personnes conservatrices
- ne pas faire deux versions la même semaine.
On obtient le modèle suivant :
| Événements | Été | Hiver |
|---|---|---|
| x.y gel des fonctionnalités | Juin (d) | Déc(d) |
| x.y.0 permière version | Août(d) | Fév(d) |
| x.y.1 version de bugfix | sept(d) | mars(d) |
| x.y.2 version de bugfix | oct(d) | avril(d) |
| x.y.3 version de bugfix | nov(d) | mai(d) |
| x.y.4 version de bugfix | déc(d) | juin(d) |
| x.y.5 version de bugfix | fév(m) | août(m) |
| x.y.6 version de bugfix | avr(m) | oct(m) |
Où (d) indique le début de mois, (m) le milieu et (f) la fin du mois.
Gel des phrases
Les plans de sortie de la première version de chaque version majeure indiquent un "hard English string & UI freeze" (gel sévère des phrases anglaises et de l'interface utilisateur). L'idée est de faciliter la vie des traducteurs. Les traducteurs doivent pouvoir être sûrs qu'aucune nouvelle chaîne traduisible n'est ajoutée à l'interface utilisateur ou aux fichiers d'aide entre la période de gel des chaînes et la sortie de la version.
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.
Après la sortie de la première version d'une version majeure, la correction des erreurs dans l'interface utilisateur et les chaînes d'aide est acceptée. Tout contenu entièrement nouveau devrait être destiné à la prochaine version majeure.
Schéma de version
Nous réalisons plusieurs builds autour de chaque version. Le schéma de versionnement utilisé est le suivant :
- X.Y.0.0.alphaZ - Zième version alpha de la version initiale
- X.Y.0.0.betaZ - Zième version bêta de la version initiale
- X.Y.0.Z - Zième version candidate de la version initiale, la dernière rc est considérée comme finale et mise sur la page principale de téléchargement.
- X.Y.1.Z - Zième version candidate de la première version de correction de bogues, la dernière rc est considérée comme finale et mise sur la page principale de téléchargement.
Il semble être le meilleur compromis avec les avantages suivants :
- facile à comprendre pour les utilisateurs normaux, les drapeaux alpha, beta sont connus d'autres projets, ils fixent donc des attentes raisonnables
- tri alphabétique correct dans RPM, Bugzilla
- facile" à analyser (chaînes alpha/beta délimitées par un point)
Il y a eu une longue discussion à ce sujet sur la liste de diffusion.
Accélérer le cycle de version
Cette accélération du cycle de publication implique des efforts considérables en matière d'ingénierie de publication et d'assurance qualité (QA). Pour réduire le coût de ces efforts, nous nous efforçons de fournir des instantanés quotidiens complets (c'est-à-dire contenant toutes les langues) de la branche principale afin de permettre le test continu des améliorations du code. Cela fonctionne déjà partiellement, comme on peut le voir/télécharger à partir de ici.
De même, nous prévoyons d'automatiser de plus en plus le processus de builds afin de réduire considérablement le nombre de versions et de continuer à réduire l'empreinte de nos binaires afin de permettre un transfert beaucoup plus rapide des builds équivalentes aux produits.
Versions en fin de vie (EOL End-Of-Life)
Une version a normalement une durée de vie d'environ neuf mois. Nous considérons qu'une version a atteint sa fin de vie (EOL) un mois après la dernière sortie prévue.
Si vous souhaitez une assistance à plus long terme pour une version, nous vous encourageons à faire appel à tout fournisseur L3 certifié susceptible de vous fournir ce service.
En raison de la quantité de données, les versions EOL ont été rangées dans les Archives.