WordCamp Paris - Contributor Day Atelier 3 - Beta tester WordPress

F5679c32509d3a0f9821da8ba4843a75?s=47 Jb Audras
December 18, 2018

WordCamp Paris - Contributor Day Atelier 3 - Beta tester WordPress

F5679c32509d3a0f9821da8ba4843a75?s=128

Jb Audras

December 18, 2018
Tweet

Transcript

  1. WordCamp Paris Contributor Day Atelier 3 : le beta-testing du

    cœur WordPress 18 décembre 2018
  2. Tester c’est douter ? Hmmm non :-)

  3. À propos du numérotage des version de WordPress

  4. “ DISCLAIMER WordPress 5 n’existe pas

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

  6. 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
  7. 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
  8. 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é ^^)
  9. Le processus de release de WordPress

  10. 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)
  11. 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
  12. Comment devient-on beta tester ?

  13. 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
  14. 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.
  15. 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
  16. Exemple de beta test : 5.0.2 RC2