Un développeur qui publie sa première extension sur le répertoire officiel WordPress.org découvre souvent avec surprise qu’il doit apprendre des commandes Subversion, un système de gestion de versions qu’il n’a peut-être jamais utilisé ailleurs dans sa carrière. Ce billet raconte pourquoi cette situation existe, sans détailler la procédure de publication elle-même.
Le contraste est net : la quasi-totalité du développement WordPress moderne, qu’il s’agisse de projets sur mesure ou de contributions au cœur du logiciel, se fait aujourd’hui avec Git. Pourtant, la distribution officielle des extensions et des thèmes, elle, continue de reposer sur Subversion.
Une décision prise avant que Git ne domine l’écosystème
Le répertoire officiel des extensions WordPress.org s’est construit à une époque où Subversion figurait parmi les systèmes de gestion de versions les plus répandus pour des projets open source de cette nature. Le choix technique fait à ce moment-là a structuré durablement l’infrastructure de distribution : chaque extension et chaque thème dispose d’un dépôt SVN dédié, avec une organisation en dossiers trunk, tags et branches propre à ce système.
Pourquoi ce choix n’a jamais été remis en cause depuis
Changer le système de distribution officiel représenterait un chantier considérable : des dizaines de milliers d’extensions et de thèmes déjà hébergés, des outils d’automatisation construits autour de cette infrastructure, et une compatibilité à préserver avec les habitudes de milliers de contributeurs. Le coût d’une migration a toujours dépassé le bénéfice perçu, d’autant que Subversion continue de remplir correctement sa fonction : distribuer un code stable et versionné à des millions d’installations WordPress.
- Le dépôt SVN de chaque extension reste la source de vérité pour les versions publiées et installées automatiquement par les sites.
- Le développement quotidien, lui, se fait très largement sur des plateformes basées sur Git, y compris pour de nombreuses extensions distribuées ensuite sur SVN.
- De nombreux mainteneurs utilisent des outils de synchronisation qui répliquent automatiquement un dépôt Git vers le SVN officiel au moment de la publication.
Deux logiques différentes, pas deux concurrents
Cette coexistence s’explique par une différence de fonction plutôt que par une résistance au changement. Git s’est imposé pour la collaboration au quotidien : branches multiples, relecture de propositions de modification, historique distribué entre plusieurs copies du dépôt. SVN, avec son modèle centralisé plus simple, correspond bien à un usage de distribution stable, où l’objectif n’est pas de collaborer sur du code en cours d’écriture, mais de publier des versions figées et numérotées destinées à des millions d’installations.
Un système ancien ne survit pas parce qu’on refuse de le remplacer, mais parce qu’il continue de remplir correctement la fonction pour laquelle il a été choisi.
Le cœur de WordPress lui-même a suivi un chemin différent
Le développement du cœur de WordPress a également connu cette dualité pendant longtemps : les contributions au code du logiciel se faisaient historiquement sur un dépôt Subversion propre au projet, avec un miroir Git en lecture seule destiné à faciliter la contribution. Cette organisation a montré, à l’échelle du cœur lui-même, la même coexistence observée pour la distribution des extensions.
Ce que cette histoire apprend sur l’écosystème
Cet exemple illustre une tendance observable ailleurs dans l’écosystème WordPress : les choix d’infrastructure pris tôt, lorsqu’ils continuent de fonctionner correctement, se maintiennent bien au-delà de la popularité relative des technologies concurrentes. Ce n’est pas un signe d’immobilisme, mais une évaluation pragmatique du rapport entre le coût d’une migration et le bénéfice réel qu’elle apporterait à des millions d’installations existantes.
En résumé
La distribution officielle des extensions et des thèmes WordPress repose encore sur Subversion, un choix hérité d’une décision d’infrastructure antérieure à la domination de Git. Cette coexistence perdure parce que les deux systèmes répondent à des besoins différents : la collaboration quotidienne d’un côté, la distribution stable de versions figées de l’autre. Comprendre cette dualité évite bien des confusions au moment de publier une extension pour la première fois.
