Installer une nouvelle version dès sa publication n’est pas toujours le seul choix possible. Pour les projets WordPress gérés avec Composer, WP Packages prend désormais en charge une politique permettant de retarder l’adoption de paquets tout juste publiés. L’objectif est de laisser une fenêtre d’observation lorsqu’une version récente pourrait être retirée après la détection d’un problème.
Dans son annonce du 29 octobre, Roots explique que WP Packages exploite la politique de cooldown de Composer 2.11 pour ses extensions et thèmes WordPress. Le délai est choisi dans la configuration du projet. Cette fonction concerne les projets utilisant cette chaîne de gestion des dépendances : elle ne modifie pas automatiquement le bouton de mise à jour de tous les sites WordPress.
Un filtre sur l’âge de la version
Le principe est de ne pas sélectionner un paquet publié trop récemment au regard de la durée configurée. Si une version plus ancienne satisfait les contraintes du projet, Composer peut retenir celle-ci. Si seule une version encore retenue par le délai convient, la résolution peut échouer en indiquant cette contrainte.
La conséquence n’est donc pas toujours une installation silencieuse de la dernière version disponible. Le comportement dépend à la fois de l’âge du paquet et des exigences exprimées par le projet. Pour les équipes, comprendre ce mécanisme évite d’interpréter chaque refus comme une panne du dépôt.
Ce délai n’est pas une analyse complète du code. Attendre quelques jours ne prouve pas qu’une version est sûre et ne remplace pas les autres vérifications. Il ajoute un critère temporel à une décision d’installation, avec les limites propres à ce critère.
Roots précise aussi que les versions de développement, comme dev-trunk, ne sont pas retenues par ce mécanisme. Ce point mérite d’être compris par les équipes qui mélangent versions publiées et dépendances de développement dans leur projet.
La date doit venir d’une source fiable
Roots souligne que WP Packages enregistre le moment où il sert une version pour la première fois. Le service ne se contente pas d’une date que l’auteur du paquet pourrait déclarer. Il explique également réinitialiser ce repère lorsqu’un tag WordPress.org est modifié, sous certaines conditions.
Cette précision technique porte sur un enjeu simple : un mécanisme d’attente perdrait de sa valeur si un acteur pouvait faire passer artificiellement une version récente pour une version ancienne. La provenance de la date fait donc partie du fonctionnement de la protection.
Pour un responsable de site, le sujet peut être discuté sans entrer immédiatement dans tous les détails de Composer. Demandez d’abord à votre prestataire comment les extensions sont distribuées, testées et déployées dans votre environnement. La réponse déterminera si cette nouveauté s’applique réellement au projet.
Retarder et corriger demandent une politique cohérente
Un délai d’observation ne doit pas devenir une règle aveugle qui retarde indéfiniment les corrections nécessaires. Les équipes ont besoin d’une procédure permettant d’examiner les alertes, de décider des exceptions et de suivre les versions effectivement installées.
La question n’est donc pas seulement « combien de jours attendre ? ». Elle porte aussi sur les personnes chargées de l’analyse, les outils utilisés pour les essais et les moyens de revenir à une situation maîtrisée si une mise à jour pose problème. Ces éléments doivent être adaptés au site et à ses contraintes.
Notre dossier sur la sauvegarde externalisée des données d’entreprise rappelle un autre volet de cette préparation. Une sauvegarde et un délai d’installation répondent à des risques différents : les examiner ensemble aide à construire une maintenance qui ne repose pas sur un seul mécanisme.
Ce qui change pour les propriétaires de sites.
Si votre site est maintenu directement depuis l’administration WordPress, cette annonce ne signifie pas qu’un nouveau réglage vient d’apparaître partout. Elle concerne un outil employé notamment dans des projets où les dépendances sont gérées de façon structurée avec Composer et un dépôt compatible.
Pour ces équipes, la nouveauté apporte une possibilité supplémentaire de formaliser l’adoption des versions. Elle peut également rendre certains choix plus visibles dans la configuration du projet, au lieu de dépendre uniquement d’une habitude informelle de mise à jour.
L’annonce de Roots illustre ainsi une évolution de la maintenance : ne plus seulement demander quelle version est disponible, mais aussi depuis quand elle l’est et dans quelles conditions elle sera retenue. Le temps devient un paramètre explicite, à articuler avec la surveillance des alertes et les besoins réels du site.
