Le développeur principal de WordPress, Andrew Ozz, a publié un proposition pour l’ajout d’un nouveau type de ticket « gutenberg-merge » qui formaliserait la latitude accordée aux contributeurs de Gutenberg pour valider le code après le gel des fonctionnalités pendant le cycle de publication.
En règle générale, toutes les nouvelles fonctionnalités et améliorations apportées à la version doivent être validées avant la version bêta 1 afin qu’elles puissent être prêtes à être testées. Auparavant, les tickets pouvaient être modifiés de « amélioration » à « tâche » juste avant la bêta 1, à l’exception rare des éléments qui n’étaient pas prêts à temps pour la bêta et qui n’avaient besoin que de quelques jours de plus pour être validés.
« L’intention était d’autoriser deux ou trois jours supplémentaires, pas une semaine ou deux », a déclaré Ozz. « Cette exception se produisait assez rarement, peut-être quelques fois par an.
« Cependant, ces derniers temps, cette exception est devenue une partie du flux de travail de publication standard. Ces dernières années, il est devenu courant que 15 à 20 tickets pour du code provenant de Gutenberg soient changés en tâches à chaque version. La raison pour laquelle ils sont modifiés n’est pas de donner aux développeurs quelques jours de plus pour les terminer. C’est surtout pour signifier qu’ils vont être engagés plus tard.
Ozz soutient que parce que le plugin de fonctionnalité Gutenberg est utilisé sur plus de 300 000 sites, y compris WordPress.com, et parce que 60 % des utilisateurs mettent rapidement à jour la dernière version, toutes les fonctionnalités et améliorations provenant de Gutenberg ont déjà été testées.
La section des commentaires de la proposition est active avec des opinions divergentes. Plusieurs participants à la discussion n’étaient pas d’accord sur le fait que ce n’est pas parce que les fonctionnalités sont dans le plugin qu’elles ont été correctement testées par rapport aux objectifs qu’elles étaient censées atteindre.
« Ce qui m’inquiète sur la façon dont cela pourrait fonctionner, c’est qu’actuellement le niveau de documentation pour les fonctionnalités qui atterrissent dans le noyau a un niveau plus élevé que les fusions de Gutenberg », a déclaré le contributeur principal Fabian Kägy. « Une fois que nous approchons de la version bêta 1, l’équipe de documentation passe en revue toutes les fonctionnalités qui ont été fusionnées au cours de ce cycle, en s’assurant qu’il existe des notes de développement pour tout changement susceptible d’avoir un impact sur les utilisateurs/développeurs. Si ce délai est raccourci, cela signifie également qu’il peut devenir plus difficile de respecter cette norme.
Kägy a également noté les défis des développeurs de plugins et de thèmes testant leurs extensions par rapport au noyau afin d’assurer la compatibilité avec la dernière version.
« Avec ce flux de travail modifié, le temps réel pendant lequel vous savez avec une assez grande probabilité quelles fonctionnalités feront partie d’une version de base donnée devient plus court, ce qui rend plus difficile d’assurer la compatibilité avec une version au moment de la sortie », a déclaré Kägy. .
Contributeur principal Peter Wilson décrit deux préoccupations avec la proposition:
- en traitant Gutenberg comme un cas particulier, cela augmentera le conflit entre ceux qui travaillent principalement dans le référentiel WordPress-Develop et ceux qui travaillent principalement dans le référentiel Gutenberg,
- contourner les exigences de gel des fonctionnalités pour l’éditeur va à l’encontre de l’affirmation selon laquelle Le noyau est Gutenberg et Gutenberg est le noyau.
Wilson a déclaré que la fusion tardive des fonctionnalités de Gutenberg était « une source de conflit depuis plusieurs années ».
« Les fusions en masse des fonctionnalités de Gutenberg à la fin du cycle ont également été un problème signalé à la fois par ceux qui travaillent principalement dans le référentiel Gutenberg et par ceux qui travaillent principalement dans le référentiel WordPress-Develop, » il a dit. « Pendant des années, des fusions incrémentielles au cours du cycle ont été préconisées mais jamais réalisées selon les commentaires dans le post lié. »
Wilson n’est pas non plus d’accord avec l’affirmation de la proposition selon laquelle les fonctionnalités développées dans le référentiel Gutenberg sont mieux testées dans le plug-in de fonctionnalités, car l’objectif des périodes bêta et RC est de tester la version dans son ensemble.
“Avec Gutenberg comme plugin remplacer les blocs de base par les versions du pluginle test de la version dans son ensemble ne se produit qu’après la fusion des modifications de l’éditeur dans WordPress-Develop », a déclaré Wilson.
« Ce n’est qu’une fois que Gutenberg est fusionné avec WordPress-Develop que les tests unitaires commencent à s’exécuter sur divers hébergeurs exécutant la suite de tests dans divers environnements. »
WordPress Core Committer Joe McGill a encouragé les auteurs de la proposition à élaborer sur les politiques et les attentes qui sera appliqué à la validation des correctifs sur les tickets désignés avec le nouveau type de ticket.
« Par exemple, tous ces commits doivent-ils être terminés avant RC-1, à moins qu’un bogue ne soit découvert pendant la période RC – et seuls les correctifs découverts soient validés, ou y a-t-il d’autres règles en jeu ? » dit McGill. « Personnellement, je pense toujours que nous devrions viser à avoir du code pour toute nouvelle fonctionnalité majeure fusionnée avant le jalon Beta-1, qu’elle soit testée dans le plugin Gutenberg ou non. »
La discussion se poursuit dans les commentaires de la proposition. Bien que les modifications proposées affectent principalement les principaux contributeurs, les committers et les responsables de publication, elles ont également un impact sur les testeurs et la communauté de développeurs de plugins et de thèmes de WordPress qui travaillent pour assurer la compatibilité avant une version majeure. Ceux qui ont des commentaires sur la façon dont les fonctionnalités de Gutenberg sont gérées pendant et après le «gel des fonctionnalités» devraient se pencher sur les commentaires du proposition.
Source link