Lors des phases de développement d’une nouvelle version de WordPress, il est possible d’aider à la livraison des versions bêta et release candidate de WP en participant aux « release parties », qui sont des événements planifiés à l’avance pour procéder à la construction d’une version bêta ou release candidate, ou d’une version finale, et à sa livraison au public.
Prérequis
- Aucun niveau technique particulier n’est nécessaire à part savoir utiliser WordPress
- Avoir un site de test installé en local ou en ligne
- Installer l’extension Beta Tester et la paramétrer (dans
Outils > Test Bêta) de la façon suivante (ici nous sommes sur une installation en anglais, si vous êtes sur une installation en français, faites la correspondance des options) :
Bleeding edge : version en cours de développement. Cette version utilise le code en cours de développement (Bleeding edge nightlies) qui peut parfois être instable. Ne l’utilisez en production que si vous savez vraiment ce que vous faites.
Bêta/RC only : ceci concerne uniquement les versions bêta/RC du canal sélectionné.
Déroulement de la release party
Les release parties se déroulent entièrement sur le Slack Make.WordPress.org, sur le canal #core. Pour le rejoindre utilisez votre nom de compte WordPress.org, ici : https://make.wordpress.org/chat/.
Généralement, il y en a pour 30-40 minutes si c’est une version beta/RC.
Normalement les release parties commencent à peu près à l’heure, souvent en fin d’après midi. Voici le déroulement :
- Message d’accueil de la personne qui dirige la release party, tout le monde fait coucou et ça permet de consigner le nombre de contributrices et contributeurs qui participent à la release
- Quelques vérifications techniques entre le ou la lead, la personne faisant office de committer (qui va créer la version de WordPress concernée) et le contrôle de mission (mission control, qui est chargé de construire le paquet ZIP de la version), ça peut prendre 10-15 minutes mais c’est souvent moins.
- Les checks de sécurité et les tests unitaires sont lancés par la personne chargée des commits et le contrôle de mission
- Le ou la core committer fait un premier commit de version
- Le contrôle de mission livre un premier ZIP de la version
- C’EST LÀ QUE VOUS INTERVENEZ ! Vous pouvez :
- (plus long) Récupérer le ZIP et l’installer en local
- (plus rapide mais plus technique) Installer la version via WP-CLI
- (recommandé) Via Beta Tester :
- Aller sur une installation avec l’extension WP Beta Tester installée, paramétrée comme expliqué ci-dessus
- Normalement, au bout de quelques secondes après que le ZIP soit disponible, vous devriez voir un petit message sur l’écran d’accueil de l’admin indiquant qu’une nouvelle version est disponible pour test
- Pensez à noter le numéro de version de WP que vous aviez avant de mettre à jour !
- Cliquez sur le lien de mise à jour et installez la version
- Les choses que vous pouvez tester :
- Fonctionnement de quelques écrans de l’admin
- Bon fonctionnement de l’éditeur : insertion d’un bloc, enregistrement d’un article
- Bon fonctionnement de l’éditeur de site (navigation dans quelques écrans)
- Bon fonctionnement de quelques écrans du front
- Bon fonctionnement de l’éditeur après installation d’un thème classique
- Bon fonctionnement de l’éditeur après installation de l’extension Classic Editor
- Si vous disposez d’une instance multisite, mentionnez-le
- Si vous avez les moyens de tester la mise à jour depuis une vieille version de WP (version 4.9 ou au dessus), c’est très utile aussi. Mentionnez la version depuis laquelle vous avez fait la mise à jour
- Une fois que vous avez testé, mettez un petit message dans le canal #core, en indiquant la version que vous aviez avant la MAJ et la version vers laquelle vous avez mis à jour. Par exemple :
Vous pourrez ensuite suivre le reste de la release party tranquillement.
Et vous serez aussi crédité·es pour votre participation à cette version. Bravo !