Cycle de vie des versions
MediaWiki utilise le modèle de développement dit d’« intégration continue », dans lequel les modifications du logiciel sont déployées régulièrement sur les sites web 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 sur la liste de diffusion mediawiki-announce, qui reçoit des annonces pour toutes les versions, 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 mediawiki-l et wikitech-l.
Versions et dates de fin de vie
| Version | Statut | Publication | Fin de vie |
|---|---|---|---|
| 1.44.x | Version future | ||
| 1.43.x (LTS) | version actuelle de maintenance à long terme | ||
| 1.42.x | version actuelle stable | ||
| 1.41.x | ancienne version | ||
| 1.40.x | version obsolète | ||
| 1.39.x (LTS) | ancienne version supportée à long terme | ||
| 1.38.x | Version obsolète |
Les versions incluses dans le tableau ci-dessus marquées comme obsolètes, ainsi que les versions absentes, ne recevront pas de correctifs de sécurité. Cela comprend aussi toutes les versions antérieures à la plus ancienne version listée. Elles peuvent contenir des vulnérabilités de sécurité critiques et d'autres bogues majeurs, y compris la menace d'une éventuelle perte et / ou corruption de données. Le responsable de la version a également émis une forte recommandation selon laquelle seules les versions listées ci-dessus comme étant la version stable, la version héritée ou la version de support à long terme actuelle doivent être utilisées dans un environnement de production.
- Développement alpha
- Développement de versions
- Version stable
- Version de support à long terme
Politique de publication
- Chaque version mineure inclura les mises à jour des fichiers i18n d’internationalisation et les corrections de bugs. Aucune nouvelle fonctionnalité ne sera intégrée dans les versions mineures et en général, la maintenance ne couvre pas nécessairement les paquets d'extensions et les habillages.
- Une version majeure sera créée tous les six mois.
- Une version mineure (y compris les correctifs de sécurité, les back-ports de traduction des messages et les corrections de bogues généraux) est publiée tous les trimestres.
- Une version de support à long terme (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.23 était maintenue jusqu’à mai 2017 ; la version 1.27 a été 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.
Calendrier des publications
Cette chronologie est un planning de ce qui doit arriver avant la publication d’une nouvelle version. La date de la publication est représentée par T (pour time) et les suffixes -n indiquent une date n semaines avant la publication.
| Date | Tâches |
|---|---|
| T - 7 | Annoncer la création de la branche de la version la semaine suivante. Demander à tous de s’assurer que toute modification nécessaire pour terminer une fonctionnalité en cours d’écriture a été incluse avant cette date. Créer le projet « MW-X.XX-release » dans Phabricator. |
| T - 6 | Créer la branche de MediaWiki et de toutes les extensions dans Gerrit. |
| T - 5 | Ajouter le marqueur X.XX-rc.0 et publier la version candidate initiale. |
| T - 4 | Collecter les signalements de bogues et les résumer sur la liste de diffusion. |
| T - 3 | Ajouter le marqueur X.XX-rc.1 et publier la seconde version de test. Toutes les nouvelles extensions dont l’ajout à l’archive de distribution est envisagé devraient y être à ce moment. Plus aucune extension n’est modifiée à partir de ce moment. |
| T - 2 | Collecter tous les nouveaux signalements de bogues, fusionner les correctifs, retirer les nouvelles fonctionnalités incomplètes insérées par accident, ajouter le marqueur X.XX-rc.2 et publier la troisième version de test. |
| T - 1 | Répéter l’étape précédente, ajouter le marqueur X.XX-rc.final et publier. Plus aucun rétroportage ne sera accepté passé cet instant. |
| T | Ajouter le marqueur X.XX et effectuer la publication. |
Gestion du cycle de vie des extensions
La plupart des installations de MediaWiki incluent un nombre significatif d'extensions (les wikis Wikimedia en ont souvent environ 140). Gérer la correction des bogues de maintenance des extensions et choisir la bonne version d'une extension dans les cas où la version de développement HEAD repose sur des fonctionnalités qui ne sont pas encore disponibles dans le noyau stable ou ancien de MediaWiki, peut être difficile.
Les mainteneurs d'extensions sont donc fortement encouragés à maintenir une branche git pour chaque version d'extension correspondant à une version de MediaWiki.
(Voir Compatibility#MediaWiki extensions pour les détails.)
Pour les extensions hébergées dans les dépôts git de Wikimedia, de telles branches (avec des noms tels que REL1_30 pour MediaWiki 1.30) sont créées automatiquement à partir du master lorsqu'une nouvelle version de MediaWiki est ramifiée (en supposant que le master de l'extension soit compatible avec le master de MediaWiki tout le temps).
Cependant, il est préférable que le mainteneur de l'extension corrige les bogues non seulement dans HEAD, mais aussi dans les versions anciennes et stables (en rétroportant le correctif sur les anciennes branches si nécessaire).
Le but de ces règles est de permettre aux personnes ou organisations installant MediaWiki de pouvoir installer la dernière version et d’y faire correspondre les extensions par une méthode simple, par exemple pour le noyau MediaWiki 1.20.x en utilisant REL1_20 dans git.
Et cela évite les archives tar et les fichiers zip avec des noms non pertinents et imprévisibles.
Voir aussi
- Informations sur la compatibilité de MediaWiki, principalement avec PHP et MySQL
- Règles des interfaces stables
- Generators sur WikiApiary : statistiques d’utilisation des versions de MediaWiki.