WordPress 7.0, initialement prévu pour le 9 avril, sera retardé afin de stabiliser la fonctionnalité de collaboration en temps réel et de garantir que la version, une étape majeure, « visera une stabilité extrême ». Beaucoup de choses dépendent de WordPress 7.0, car il sera livré avec des fonctionnalités qui inaugureront l’ère des systèmes de gestion de contenu basés sur l’IA.
Priorité à la stabilité
Matt Mullenweg, co-fondateur de WordPress, commentant dans l’espace de travail officiel Making WordPress Slack, a déclaré que la version devrait prendre du recul par rapport à sa trajectoire actuelle et donner la priorité à la stabilité, appelant à une phase de pré-version plus longue pour que la fonctionnalité de collaboration en temps réel (RTC) fonctionne correctement. Le retard devrait durer des semaines, et non des jours, et est décrit comme un écart ponctuel par rapport au calendrier prévu par WordPress.
Mullenweg a publié :
« Compte tenu de la portée et du statut de la version 7.0, je pense que nous devrions revenir aux versions bêta, mettre au point les nouvelles tables, verrouiller tout ce que nous voulons pour la version 7.0, puis relancer les RC. La gestion des dates est toujours notre valeur par défaut, mais pour cette version marquante, nous souhaitons cibler une stabilité extrême et des mises à jour passionnantes, d’autant plus que le développement accéléré par l’IA augmente les attentes des gens en matière de logiciels.
Il s’agit d’un événement ponctuel, je pense qu’à l’avenir, nous devrions revenir au train régulier, avec un objectif de 4 trains par an en 2027, pour, espérons-le, refléter notre capacité, grâce à l’IA, à aller plus vite.
La phase de version candidate étendue remplace la réversion bêta
Pour éviter les problèmes de compatibilité technique, le projet restera en phase de version candidate, prolongeant la période de test via des versions RC supplémentaires si nécessaire.
La proposition de revenir aux versions bêta a été rejetée car elle briserait le comportement de comparaison des versions de PHP, la logique de mise à jour des plugins et les outils qui dépendent du séquençage standard des versions. Continuer avec les versions RC préserve la compatibilité tout en accordant plus de temps pour les tests et les correctifs.
Collaboration en temps réel
Le retard est en grande partie dû à la fonctionnalité de collaboration en temps réel, qui introduit de nouvelles tables de base de données et modifie la façon dont WordPress gère les sessions d’édition. Les contributeurs ont identifié des risques liés aux performances, à la gestion des données et aux interactions avec les systèmes existants.
L’une des principales préoccupations est que l’édition en temps réel désactive actuellement les caches de publication persistants pendant les sessions actives, un problème de performances que l’équipe s’efforce de résoudre avant la version finale.
La conception de bases de données soulève des problèmes de performances
Une partie clé de la discussion s’est concentrée sur la manière de structurer la base de données pour la collaboration en temps réel (RTC). Une table RTC unique proposée prendrait en charge 1. les mises à jour d’édition en temps réel et 2. la synchronisation. Mais certains contributeurs ont noté que les charges de travail liées à l’édition et à la synchronisation en temps réel sont fondamentalement différentes.
La collaboration en temps réel génère des écritures en rafale à haute fréquence qui nécessitent une faible latence (ce qui signifie que les mises à jour s’effectuent avec très peu de retard).
La synchronisation entre les environnements implique des mises à jour plus lentes et structurées pouvant inclure des analyses de tables complètes.
La combinaison des deux modèles dans une seule table risque de problèmes de performances et d’une complexité accrue. Les contributeurs ont discuté de la séparation de ces charges de travail dans des tableaux distincts optimisés pour chaque cas d’utilisation, mais aucune décision n’a été prise.
Les lacunes dans les tests des candidats à la libération suscitent des inquiétudes
La discussion dans l’espace de travail WordPress Slack a également soulevé des inquiétudes quant à savoir s’il y avait suffisamment de tests de versions candidates dans le monde réel, et les modifications du schéma de base de données augmentent le risque d’échecs lors des mises à niveau. La solution consistant à utiliser le plugin Gutenberg pour les tests a été rejetée car les modifications de la base de données pourraient affecter les sites de production et nécessiter une logique de migration complexe. Au lieu de cela, le projet utilisera une phase RC étendue pour augmenter l’exposition aux tests et recueillir les commentaires d’un groupe plus large d’utilisateurs.
Contraintes de gestion des versions
La proposition de retarder la version 7.0 a entraîné des problèmes supplémentaires. Les règles de comparaison des versions PHP et les outils associés compliquent le retour aux versions bêta. Il a été convenu que le fait de rester dans la séquence des versions candidates (par exemple RC1, RC2, RC3) évite ces problèmes tout en permettant une itération continue. Il a donc été décidé de continuer avec les versions candidates.
La cadence des versions futures demeure
Le retard est décrit comme une exception temporaire. Matt Mullenweg a déclaré que le projet avait l’intention de revenir à un calendrier de publication régulier, avec pour objectif de livrer environ quatre versions par an d’ici 2027, à mesure que les vitesses de développement augmentent grâce aux flux de travail assistés par l’IA.
Implications pour les développeurs et les utilisateurs
Les développeurs doivent s’attendre à des modifications continues de la fonctionnalité de collaboration en temps réel et de ses structures de base de données de support pendant la phase de version candidate étendue. La période de test plus longue donne plus de temps pour identifier les problèmes avant la sortie. Pour les propriétaires et les hébergeurs de sites, le retard montre que WordPress donne la priorité à la stabilité plutôt qu’au calendrier tout en introduisant des fonctionnalités de temps réel et de synchronisation plus complexes.
Impact du RTC sur les environnements d’hébergement
Quelque chose qui n’a pas été abordé mais qui constitue un véritable problème est la manière dont la collaboration en temps réel pourrait affecter les fournisseurs d’hébergement Web. Ils doivent tester cette fonctionnalité pour voir si elle introduit des problèmes sur les environnements d’hébergement partagé. Bien que RTC soit livré avec la fonctionnalité désactivée par défaut, l’impact de son utilisation par les clients dans un environnement d’hébergement partagé est actuellement inconnu. Un porte-parole du fournisseur d’hébergement WordPress géré Kinsta a déclaré au Search Engine Journal qu’ils étaient toujours en train de tester. Étant donné que la fonctionnalité continue d’évoluer, Kinsta et d’autres hébergeurs Web devront continuer à tester les prochaines versions candidates de WordPress.
Je pense que la plupart des gens conviendront que la décision de retarder la sortie de WordPress 7.0 est la bonne décision.
Commentaires