Version lifecycle/fr

MediaWiki utilise le modèle de développement dit d’« intégration continue », dans lequel les modification du logiciel sont déployées régulièrement sur les sites Wikimedia tels que Wikipédia.

En théorie, de nouvelles versions majeures sont publiées tous les six mois et les branches de ces versions reçoivent des mises à jour de sécurité jusqu’à un an après la première publication. À cause des contraintes de temps et la restructuration rapide du code de base, nous ne pouvons pas maintenir indéfiniment ; les mises à jour de sécurité et les mises à jour critiques ne sont donc pas disponibles pour les versions ayant atteint le statut de fin de vie.

Le responsable de la publication recommande fortement aux administrateurs de wikis de s’inscrire à la liste de diffusion, qui reçoit des annonces pour toutes les publications, et de s’assurer que leur wiki fonctionne avec la version la plus à jour possible du logiciel. Ces annonces sont aussi envoyées aux listes  et.

Versions et dates de fin de vie
Les versions marquées comme obsolètes dans ce tableau ne recevront aucune mise à jour de sécurité. Elles peuvent contenir des failles critiques et des bugs majeurs, pouvant causer des pertes ou des corruptions de données. Le responsable de la publication recommande fortement que seules les versions marquées version actuelle ou version maintenue soient utilisées en production.

Politique de publication

 * Une version majeure sera créée tous les six mois.


 * Une version à support long (LTS ) sera créée tous les deux ans. Il y aura un recouvrement d’un an entre les périodes de maintenance des LTS. Par exemple, la version 1.19 est maintenue jusqu’à mai 2015 ; la version 1.23 sera publiée un an avant afin d’avoir un an pour faire la transition d’une version LTS à l’autre.


 * Les notes de versions resteront la méthode de base pour voir ce qui a changé. À cause de la nature des projets conduits par des bénévoles, il n’est pas possible de dire avec certitude ce qui arrivera dans les prochains six ou douze mois.


 * Pour réduire le problème des notes de version, nous publieront une liste des nouvelles fonctionnalités de la nouvelle LTS par rapport à la précédente six mois avant que la nouvelle soit publiée. Cela signifie que lorsque la version 1.22 sera publiée, nous annoncerons aux utilisateurs de la version 1.19 les changements qu’il peuvent espérer dans la version 1.23.


 * Des versions mineures seront créées au minimum chaque mois, le dernier jeudi du mois. Chaque version mineure inclura des mises à jour des fichiers d’internationalisation et des corrections de bugs. Aucune nouvelle fonctionnalité ne sera intégrée dans les versions mineures et la maintenance ne s’étend pas aux extensions en général, voir après (par exemple, Extension:UniversalLanguageSelector ne fonctionne pas avec la LTS actuelle).

Extension lifecycle management
Most MediaWiki installation include a significant number of extensions (WMF MediaWikis often around 80 extensions). Managing the maintenance bug fixing of extensions and choosing the right version of an extension in cases where the HEAD development version relies on features not yet available in stable or oldstable MediaWiki core, is a major challenge for all maintainers of MediaWiki installations.

Extension maintainers are therefore strongly encouraged to maintain a git tag or branch for their version corresponding to the release tag the stable and oldstable version. An initial version, that simply points to the state of the code at the time of the release may be created centrally. However, it is the responsibility of the extension maintainer to fix bugs not only in HEAD but also in the oldstable and stable versions. If the extension works with all of oldstable, stable and HEAD, this requires only to update the tags. However, if some changes are specific to later versions, the lifecycle rule require that branches are created and individual merges of the bugfix to each branch be made.

The goal of these rules is that people or organizations installing MediaWiki can rely on installing the newest release of a version and matching extensions by a simple method, e.g. for 1.20.x core by referring to REL1_20 in git.