Hier, Francesca Marano a ouvert un proposition de changement de phase du cycle de publication de base de WordPress. C’était un récapitulatif d’un discussion le a commencé en octobre 2020. L’objectif est d’aligner les phases de la plate-forme sur la norme plus large de l’industrie du développement.
Outre la dénomination, WordPress a principalement suivi l’industrie du logiciel dans la façon dont il aborde son cycle de publication. Suivre une convention bien connue peut faciliter la transition des développeurs en dehors de l’écosystème WordPress. Cela permettrait également aux développeurs de suivre les cycles d’autres projets, dont beaucoup sont des dépendances WordPress. Ce type de standardisation est généralement considéré comme une bonne chose dans le monde du développement logiciel.
Sur la base des discussions en cours depuis octobre, il existe un consensus sur le changement de nom des phases pour s’aligner sur la norme. Le tableau suivant montre en quoi chaque phase serait renommée:
| Phase | Nom actuel | Nom proposé |
|---|---|---|
| 1 | Planifier et sécuriser les chefs d’équipe | Planification préliminaire |
| 2 | Le travail de développement commence | Alpha |
| 3 | Bêta | Bêta |
| 4 | Libérer le candidat | Libérer le candidat |
| 5 | lancement | Publication générale |
Cependant, il s’agit d’une proposition en deux parties. Le simple fait de renommer les phases ne change pas le fonctionnement du cycle de publication. Pour suivre strictement la norme, WordPress devrait également changer lorsque le code est engagé.
Comment gérer la phase bêta
Il y a un point de discorde sur la façon de gérer la phase bêta. La norme n’appelle aucun changement de code supplémentaire autre que de nouvelles corrections de bogues introduites plus tôt dans le cycle. Pour le projet WordPress, cela crée un problème.
WordPress aura 18 ans cette année. Au fil des ans, il a accumulé une tonne de bugs plus anciens. Ceux-ci sont souvent corrigés plus tard dans le cycle, parfois pendant la phase Bêta. Ces bogues plus anciens n’ont peut-être pas fait partie de la phase de planification préliminaire, mais cela signifie-t-il qu’ils devraient attendre la prochaine version pour entrer? En suivant strictement la proposition, ils devraient être mis en attente.
Cela introduirait également un gel définitif sur toutes les améliorations définies pour la version mais incomplètes.
«Je crains que nous ne laissions pas la place pour les bogues plus anciens qui ne sont pas spécifiques aux fonctionnalités prévues dans la version», a écrit Josepha Haden dans un commenter la discussion initiale. «Je crains également qu’en appelant hard freeze plus tôt dans le processus, nous réduisions trop la fenêtre d’inclusion de fonctionnalités. Je n’aime pas nous limiter à présenter des bogues spécifiques pour le moment, car cela exclut un grand nombre de nos contributeurs bénévoles. Il est plus difficile de travailler sur les fonctionnalités car elles sont complexes et évoluent rapidement, et les bogues plus anciens offrent plus d’opportunités aux contributeurs occasionnels. »
D’un autre côté, il est possible qu’une correction de bogue puisse introduire de nouveaux bogues imprévus. Plus il est ajouté tard pendant la bêta, moins de tels bogues sont susceptibles d’être remarqués avant la phase de publication générale. Attendre le cycle suivant donne plus de temps pour les tests.
L’un des avantages de ce système est que presque aucun nouveau bogue ne sera créé pendant la bêta. Cela permettrait aux volontaires de déployer davantage d’efforts pour tester et résoudre les problèmes qui sont apparus dans Alpha.
WordPress a toujours marché au rythme de son propre tambour. Il peut suivre de plus près les normes tout en se libérant des limites strictes lorsqu’il est logique de le faire pour le projet. Les correctifs de bogues de la phase bêta non destinés à une version particulière pourraient être traités au cas par cas. Nous avons des gens à des postes de direction qui sont capables de faire ces appels lorsqu’ils se présentent. Avec les mises à jour automatiques pour les versions mineures, je suis moins préoccupé par les bogues de stade avancé.
Tonya Mork proposé deux solutions pour que le travail sur les défauts continue pendant et autour du cycle de libération. Les deux nécessiteraient que WordPress se sépare de la version bêta, offrant aux contributeurs un moyen de faire avancer la résolution des bogues.
La première proposition appelle à un gel des fonctionnalités plus tôt, prévoyant deux ou trois semaines avant la Bêta 1. Cette période à la fin de la phase Alpha serait uniquement consacrée au travail sur les défauts.
La deuxième solution déplace ce travail de défaut pour chevaucher la version bêta et la version candidate de la version précédente. Cela permet au travail de se poursuivre entre les versions majeures. Cela pourrait également raccourcir le cycle global des versions majeures.
Cette seconde solution est également cohérente avec les réflexions de Joost de Valk sur le traitement des défauts. « Je pense que nous devrions simplement bifurquer plus tôt et garder le coffre ouvert pour les affaires normales, » il a dit sur la proposition. « De cette façon, tout peut être travaillé tout le temps, mais il ne sera pas inclus dans la prochaine version en fonction du moment où vous le validez. C’est bien, tous les logiciels open source que je connais dans le monde fonctionnent comme ça, à l’exception de WordPress. »
De nombreux développeurs d’extensions et de thèmes ont déjà du mal à suivre le rythme lorsque les modifications tombent dans les phases Beta ou Release Candidate. Avoir un point clair et défini où les changements de terrain bénéficieront à l’écosystème d’extension, aidant également les utilisateurs finaux à long terme. Cette deuxième solution ferait cela.
Il n’y a rien de mal non plus à combiner les deux solutions. Puisque le plan serait de bifurquer à la phase bêta, la deuxième solution est déjà en place par l’acte de branchement. La vraie discussion est de savoir si le projet doit consacrer un bloc de temps pendant sa phase Alpha qui se concentre uniquement sur les corrections de bogues.
Les commentaires sur la proposition sont ouverts jusqu’au 20 janvier avant de passer à une décision finale.
La prochaine proposition: gestion des versions sémantique, n’importe qui? N’importe qui? Est-ce que ce truc est allumé?
Source link