Chapitre 5 — Les versions de Moodle et le cycle de release

Partie 1 : Découvrir Moodle — Chapitre 5/5 Public : développeur web débutant sur Moodle. Dernier chapitre « sans code » : on apprend à lire une version, à comprendre le rythme des sorties, et à en tirer les conséquences pour votre code. Version de référence : Moodle 5.2 (sortie le 20 avril 2026).

⏱️ TL;DR

• Une version Moodle se lit MAJEURE.MINEURE (ex. 5.2) ; les correctifs ajoutent un troisième nombre (5.2.1, 5.2.2…), publiés ~toutes les 4 semaines.
• Le rythme est semestriel : une version majeure ou mineure environ tous les 6 mois (avril et octobre). Depuis la 4.x, la distinction « majeure/mineure » s’est estompée : chaque sortie apporte des nouveautés.
• Une version sur ~quatre est une LTS (Long Term Support), maintenue plus longtemps (sécurité) — cible privilégiée des institutions prudentes.
• Chaque version a trois fenêtres de support : general support (bugs + sécurité), puis security-only (sécurité seule), puis fin de vie (plus aucun correctif).
• En base, la version se traduit par un entier YYYYMMDDXX ($CFG->version) ; en git, par une branche MOODLE_502_STABLE. Ces deux formes vous serviront concrètement.
• Choisir une version de projet : viser la dernière stable (ou la dernière LTS si l’on privilégie la stabilité), jamais une version en fin de vie, et vérifier la compatibilité des plugins et de l’environnement (PHP, base de données).
• Le cycle rapide (2 sorties/an, ~1 an de support général) a une conséquence directe : un plugin ou un thème doit être testé et remis à jour à chaque version — d’où l’importance des tests et de la CI (Partie 11).
• Prérequis d’environnement de la 5.2 : PHP 8.3+, PostgreSQL 16 / MySQL 8.4 / MariaDB 10.11+, et la racine web sur public/ (changement structurel de la 5.1).

🎯 Objectifs

À la fin de ce chapitre, vous saurez :

• Lire un numéro de version Moodle et ses trois formes (humaine, base de données, branche git).
• Expliquer le cycle de release semestriel et le rôle des LTS.
• Distinguer les fenêtres de support (général, sécurité, fin de vie) et pourquoi c’est critique.
• Choisir la version d’un nouveau projet et vérifier la compatibilité plugins + environnement.
• Anticiper l’impact du cycle sur la maintenance de vos plugins et thèmes.

1. Pourquoi la question des versions est stratégique

En JavaScript, vivre une version de retard est souvent bénin. Dans Moodle, la version détermine trois choses simultanément qui peuvent bloquer un projet entier :

1. La sécurité — une instance en fin de vie ne reçoit plus aucun correctif de sécurité. Sur un LMS qui héberge des données d’étudiants (RGPD !), c’est une faute grave, parfois une non-conformité légale.
2. La compatibilité des plugins — un plugin tiers annonce les versions de Moodle qu’il supporte (chapitre 4). Choisir une version trop récente ou trop ancienne peut vous priver d’un plugin indispensable.
3. La compatibilité de l’environnement — chaque version impose une fourchette de PHP et de base de données. La 5.2 exige PHP 8.3+ : sur un serveur bloqué en PHP 8.1, vous ne pourrez tout simplement pas l’installer.

Comprendre le cycle, c’est donc pouvoir répondre à « sur quelle version part-on, et jusqu’à quand tiendra-t-elle ? » — une question qu’un décideur vous posera, et dont dépend le coût de maintenance du projet.

2. Anatomie d’un numéro de version

2.1 La forme humaine : MAJEURE.MINEURE[.CORRECTIF]

• 5 = version majeure.
• 5.2 = deuxième sortie de la série 5 (une « mineure » au sens historique, mais riche en nouveautés).
• 5.2.1, 5.2.2… = releases de maintenance (correctifs de bugs et de sécurité), publiées environ toutes les 4 semaines sur les branches maintenues.

⚠️ Piège de vocabulaire : depuis la série 4.x, Moodle a abandonné la distinction rigide majeure/mineure. On parle surtout de « versions » sorties deux fois par an. Ne cherchez pas de « grande » 6.0 opposée à une « petite » 5.2 : chaque sortie semestrielle apporte de vraies fonctionnalités. La numérotation 5.0 → 5.1 → 5.2 → … progresse, et une nouvelle « dizaine » (6.0) marque simplement le passage à une nouvelle série.

2.2 La forme base de données : $CFG->version

Moodle range en interne un entier daté de la forme YYYYMMDDXX (année, mois, jour, deux chiffres d’incrément). Exemple parlant : 2026042000. On le trouve :

• dans $CFG->version (la version du code core installé),
• dans le version.php de chaque plugin (vous en écrirez, Partie 6),
• comparé au numéro stocké en base pour décider s’il faut jouer une mise à niveau.

C’est ce nombre monotone croissant qui pilote tout le mécanisme d’upgrade : « le code sur le disque est plus récent que ce qui est enregistré en base → lance le processus de mise à jour ». Retenez la logique ; les détails sont en Partie 4 (installation) et Partie 6 (version.php d’un plugin).

2.3 La forme git : MOODLE_502_STABLE

Le dépôt (chapitre 4) organise les versions en branches stables nommées MOODLE_XYZ_STABLE, où XYZ encode la version : MOODLE_405_STABLE (4.5), MOODLE_500_STABLE (5.0), MOODLE_502_STABLE (5.2). La branche main porte le développement de la future version. Concrètement, déployer/upgrader consiste souvent à basculer d’une branche stable à la suivante puis à jouer l’upgrade (Partie 11).

💡 Pour un dev React : comparez aux trois « vues » d’une release npm : le tag lisible (5.2.1, comme un semver), le champ interne qui déclenche des migrations (ici l’entier YYYYMMDDXX, jouant le rôle d’un numéro de migration Prisma), et la branche/tag git de déploiement. Différence majeure avec semver : Moodle ne promet pas de compatibilité descendante d’API entre majeures de la même façon — d’où la nécessité de tester à chaque version (§6).

3. Le cycle de release : deux sorties par an

Moodle suit un calendrier semestriel régulier : une version en avril, une en octobre, chaque année. La 5.2 est ainsi sortie le 20 avril 2026 ; la suivante (5.3) est attendue en octobre 2026.

Entre deux versions majeures/mineures, chaque branche maintenue reçoit des releases de maintenance (.1, .2, …) toutes les ~4 semaines : correctifs de bugs et patchs de sécurité groupés. C’est pourquoi une instance bien tenue n’est pas « figée sur 5.2 » mais suit 5.2.1, 5.2.2… au fil des semaines.

⚠️ Piège : « être à jour » ne veut pas dire « être sur la dernière majeure ». Une instance en 5.2.3 est parfaitement à jour de sécurité même si la 5.3 est sortie, tant que la 5.2 est dans sa fenêtre de support. Distinguez suivre les correctifs de sa branche (obligatoire) et changer de branche majeure (planifié, plus lourd).

4. LTS et fenêtres de support

4.1 Qu’est-ce qu’une LTS ?

Environ une version sur quatre est désignée LTS (Long Term Support). Une LTS bénéficie d’une fenêtre de support de sécurité étendue par rapport aux versions intermédiaires. Les institutions qui privilégient la stabilité (universités, grandes administrations) calent souvent leur cycle sur les LTS : elles sautent les versions intermédiaires et n’upgradent qu’à la LTS suivante. La 5.3 (octobre 2026) est la prochaine LTS annoncée — d’où la note du README : ce qui est écrit pour la 5.2 s’applique à la 5.3.

4.2 Les trois fenêtres de support

Chaque version traverse trois phases :

⚠️ Piège critique : une instance en fin de vie est une passoire de sécurité et un risque de conformité (RGPD). C’est l’une des premières choses à auditer en reprenant un projet Moodle existant : « sur quelle version tourne la prod, et est-elle encore supportée ? ». Si la réponse est « 3.9 » ou « 4.1 » depuis longtemps, l’upgrade n’est pas une option, c’est une urgence.

📚 Aller plus loin : le calendrier officiel des sorties et des fins de support est publié et tenu à jour sur moodledev.io/general/releases . Vérifiez-y les dates exactes de fin de support de la version qui vous concerne — elles évoluent.

5. Choisir la version d’un projet

Vous démarrez un projet (nouvelle instance, nouveau plugin, nouveau thème). Quelle version viser ?

Règle par défaut : la dernière version stable (ici 5.2). Vous bénéficiez des dernières fonctionnalités, du support le plus long devant vous, et de la compatibilité avec les plugins récents.

Variante « stabilité d’abord » : la dernière LTS. Pour un client averse au risque ou qui n’upgrade que rarement, viser une LTS maximise la durée de tranquillité entre deux migrations lourdes.

Trois vérifications avant de graver la décision :

1. Les plugins indispensables sont-ils compatibles ? Faites la liste des plugins tiers requis et croisez-la avec leur compatibilité annoncée (chapitre 4). Un seul plugin critique incompatible peut imposer de rester une version en arrière — ou de trouver une alternative.
2. L’environnement suit-il ? La 5.2 exige PHP 8.3+ et des versions minimales de base de données (PostgreSQL 16, MySQL 8.4, MariaDB 10.11+). Si l’hébergement est bloqué sur une vieille PHP, réglez ça avant de choisir la version de Moodle.
3. La version est-elle encore supportée pour toute la durée du projet ? Ne partez jamais sur une version proche de sa fin de vie « parce que le client la connaît ».

💡 Pour un dev React : c’est le même arbitrage que choisir Node LTS vs Node « current » pour un nouveau service — sauf que le coût d’un mauvais choix est plus élevé (données d’étudiants, migrations base de données non triviales, plugins tiers à la traîne). Dans le doute pour de la production institutionnelle : dernière LTS. Pour du développement et de l’apprentissage (ce cours) : dernière stable (5.2), pour être au plus près de l’avenir.

6. Ce que le cycle implique pour VOTRE code

C’est le point qui vous concerne directement en tant que développeur, et il change des habitudes du monde JS.

Deux sorties par an = deux occasions par an que votre plugin casse. Chaque version de Moodle peut modifier une API, déprécier une fonction, changer un template ou un comportement du core. Un plugin « qui marche » en 5.1 n’est pas garanti de marcher en 5.2. Conséquences pratiques :

• Déclarez les versions supportées dans le version.php de votre plugin ($plugin->supported, $plugin->requires — Partie 6) et tenez-les à jour.
• Testez à chaque version. Sans suite de tests, chaque sortie majeure est une loterie que vous perdrez tôt ou tard, en production. D’où l’insistance de la Partie 11 sur PHPUnit, Behat et la CI (moodle-plugin-ci teste justement votre plugin contre une matrice de versions de Moodle × PHP × base de données).
• Suivez les guides de migration (les Upgrade / API change notes sur moodledev.io) : à chaque version, Moodle publie la liste des changements d’API et des dépréciations. C’est votre checklist de compatibilité.
• Gérez des branches git alignées sur les versions de Moodle si vous maintenez un plugin pour plusieurs versions (une branche par MOODLE_XYZ_STABLE supportée) — stratégie détaillée en Partie 6 (cycle de vie et distribution).

⚠️ Piège : ne jamais « figer » une instance sur une vieille version pour éviter de mettre à jour vos plugins. Vous accumulez une dette qui explose au moment de l’upgrade forcé (fin de vie, faille), avec potentiellement plusieurs versions de Moodle à franchir d’un coup. Le bon rythme : suivre, tester tôt sur les release candidates, corriger au fil de l’eau.

💡 Pour un dev React : mentalement, un plugin Moodle se maintient comme une librairie open source que vous publieriez sur npm avec une matrice de compatibilité (« supporte Moodle 5.1, 5.2 »). La CI qui teste contre plusieurs versions, c’est votre GitHub Actions habituel — transposé à l’écosystème PHP/Moodle. La discipline est la même ; seuls les outils changent.

7. Le cas particulier de la 5.2 (et de la 5.1)

Deux évolutions structurelles récentes méritent d’être connues dès maintenant, car elles influencent l’installation et le développement (détaillés en Partie 4) :

• La racine web public/ (depuis la 5.1). Historiquement, la racine web de Moodle était le dossier dirroot lui-même (tout le code exposé sous le document root). Depuis la 5.1, le point d’entrée web est le sous-dossier public/, ce qui améliore la sécurité (le code non public n’est plus servi directement). La 5.2 confirme ce modèle. Concrètement, votre document root Apache/Nginx pointe désormais sur .../public/, et certains chemins d’URL/de fichiers en tiennent compte.
• Prérequis modernisés. La 5.2 impose PHP 8.3+ (fini PHP 8.1) et des bases de données récentes (PostgreSQL 16, MySQL 8.4, MariaDB 10.11+). C’est cohérent avec le rythme : chaque version relève régulièrement le plancher pour profiter des nouveautés du langage et abandonner ce qui est en fin de vie côté PHP.
• Continuité vers la 5.3 (LTS). Comme indiqué en tête de cours, l’essentiel de ce que vous apprenez sur la 5.2 s’appliquera à la 5.3 d’octobre 2026 : les APIs, la structure des plugins, les thèmes et les web services évoluent, mais par incréments compatibles documentés, pas par rupture totale.

📚 Aller plus loin : les nouveautés détaillées de chaque version (côté utilisateur et côté développeur) sont dans les Release notes sur docs.moodle.org (fonctionnel) et les Developer update notes sur moodledev.io (API). Lire ces deux pages à chaque sortie est une habitude de développeur Moodle sérieux.

8. Synthèse et points à retenir

• Une version se lit MAJEURE.MINEURE[.CORRECTIF] (5.2, 5.2.1…) et existe sous trois formes : humaine (5.2), base de données (YYYYMMDDXX, pilote l’upgrade) et git (MOODLE_502_STABLE, pilote le déploiement).
• Le cycle est semestriel (avril / octobre) ; les correctifs (.1, .2) sortent ~toutes les 4 semaines. Une version sur ~quatre est une LTS.
• Trois fenêtres : general support (bugs + sécurité) → security-only → fin de vie (rien). Une instance en fin de vie est un risque de sécurité et de conformité.
• Choisir une version : dernière stable par défaut (dernière LTS si stabilité prioritaire), après avoir vérifié la compatibilité des plugins et de l’environnement (PHP 8.3+, BDD récentes pour la 5.2).
• Le cycle rapide impose de tester et maintenir vos plugins/thèmes à chaque version — d’où tests + CI (Partie 11). Ne figez jamais une instance pour fuir les mises à jour.
• Spécificités récentes : racine web public/ (depuis 5.1), prérequis modernisés, continuité annoncée vers la 5.3 LTS.

✏️ Exercices

Exercice 1 — Traduire une version. Donnez les trois formes (humaine, base de données approximative, branche git) de la version « Moodle 5.2 sortie le 20 avril 2026 ». Expliquez à quoi sert chaque forme.

Exercice 2 — Est-ce à jour ? Une prod tourne en 5.2.4 alors que la 5.3 vient de sortir. Le client s’inquiète d’être « en retard ». Que répondez-vous ?

Exercice 3 — Choisir pour un client prudent. Une université veut une nouvelle instance et déteste les migrations. Nous sommes en avril 2026. Quelle version recommandez-vous et pourquoi ? Que vérifiez-vous avant ?

Exercice 4 — Diagnostic d’une reprise de projet. Vous reprenez la maintenance d’un Moodle en 4.1, jamais mis à jour depuis 2023. Quels sont les deux risques majeurs, et quelle est la priorité ?

Exercice 5 — Impact sur un plugin. Vous maintenez un plugin d’activité compatible 5.1. La 5.2 sort. Quelles actions entreprenez-vous, et pourquoi ne pas simplement « attendre que ça casse » ?

🧠 Quiz de révision

Q1. Quelles sont les trois formes d’un numéro de version Moodle et à quoi sert chacune ?

Q2. À quel rythme sortent les versions, et à quel rythme les correctifs ?

Q3. Qu’est-ce qu’une LTS et pour qui est-elle indiquée ?

Q4. Pourquoi une instance en « fin de vie » est-elle un problème grave ?

Q5. Citez deux conséquences concrètes du cycle semestriel sur la maintenance d’un plugin.

Fin de la Partie 1. Vous savez désormais ce qu’est Moodle, vous parlez sa langue, vous savez naviguer dans son interface, vous connaissez son écosystème et vous comprenez son cycle de vie. Le décor est planté — place à la mécanique.

Partie suivante : Partie 2 — Administration, rôles et permissions. On entre dans le premier grand système structurant de Moodle : contextes, rôles et capabilities — le modèle de permissions qui, une fois compris, éclaire tout le reste (et que l’on retrouvera dans chaque ligne de code sécurisé).