WordCamp Paris Contributor Day Atelier 3 : le beta-testing du cœur WordPress 18 décembre 2018

Tester c’est douter ? Hmmm non :-)

À propos du numérotage des version de WordPress

“ DISCLAIMER WordPress 5 n’existe pas

“ Déjà cinquante versions… :) WordPress 5.0 = WP50

Notation : Décimal VS SemVer Le versioning sémantique est la notation la plus connue : MAJOR.MINOR.PATCH 4 . 9 . 6 puis 4.10, 4.10.1, 5.0, 5.0.1… Mais WordPress utilise une notation pseudo-décimale : MAJOR.MAJOR.MINOR 4 . 9 . 6 puis 4.9.7, 5.0, 5.0.1, 5.1

Major VS Minor Une version majeure (4.9, 5.0, 5.1…) intègre des ajouts de fonctionnalités, des améliorations, des corrections de bugs et potentiellement des changements dans la structure même du logiciel. 4.4 => Twenty Sixteen, images responsive, embeds, API Rest… 4.7 => Twenty Seventeen, API Rest content endpoints, Theme Starter Content, PDF Thumbnails, modifs éditeur TinyMCE 4.9 => CodeMirror, Media Widgets… 5.0 => Nouvel éditeur, Twenty Nineteen

Major VS Minor Une version mineure (4.9.5, 4.9.9, 5.0.1, 5.0.2…) ne doit pas intégrer d’ajout de nouveau fichier dans la structure du CMS. Elle comprend surtout des correctifs et de petites améliorations auto-contenues (self contained) qui se n’ont pas d’impact plus large que leur seule fonction. Deux types : - Version mineure de maintenance (gérées par une équipe lead) - Version mineure de sécurité (gérées par le mission control) (ou les deux : Version mineure de maintenance et de sécurité ^^)

Le processus de release de WordPress

Un déroulement cadencé LANCEMENT ◉ Choix de l’équipe lead ◉ Choix des nouvelles fonctionnalités PHASE “ALPHA” (non nommée) ◉ Mise en place des nouvelles fonctionnalités ◉ Triage des tickets ◉ Ajout du nouveau thème, MAJ des thèmes natifs, mise à jour des extensions natives ◉ Résolution des tickets PHASE “BETA” ◉ Beta 1, Beta 2, Beta 3, Beta 4… ◉ Triage des tickets ◉ Résolution des tickets PHASE “RELEASE CANDIDATE” Le logiciel pourrait sortir tel quel. ◉ RC1, RC2… ◉ Triage des tickets ◉ Résolution des tickets RELEASE FINALE (NOTE : les MAJ de sécurité seules sont poussées directement)

Chacun son rôle ◉ Project lead et lead developers : conseils et aide/prise de décision ◉ Mission control & security team : création des packages beta, RC, release finale et intégration des patches de sécurité ◉ Core committers : intégration des tickets dans le cœur ◉ Component maintainers : conseil sur les composants concernés ◉ Core contributors : création de tickets, test des versions beta/RC, participation au développement de fonctionnalités et de correctifs

Comment devient-on beta tester ?

Participer au tests publics Les versions beta et RC sont mises à disposition publiquement. Les nouveaux thèmes natifs ou features as plugins également https://make.wordpress.org/cor e ou https://make.w.org/test

Participer aux tests de Packages avant mise en public Avant d’être mis à disposition publiquement les packages de versions sont proposés en test semi-public sur le Slack Make WordPress. En cas de mise à jour de sécurité, c’est un bon voyage dans le temps qui vous attend avec des tests de WP 3.7.x à la branche majeure courante.

Remonter les problèmes Les phases de beta test et de release candidates sont accompagnées de la liste des bugs corrigés et améliorations apportées. Les remontées de problèmes se font sur Trac : => https://core.trac.wordpress.org Ou directement sur l’article d’annonce de la version beta/RC : => https://make.wordpress.org/core Ou sur Github pour les projets spécifiques : => https://github.com/WordPress/gutenberg

Exemple de beta test : 5.0.2 RC2