Distributor: Publier la version 1.6.0

Ce problème concerne le suivi des modifications pour la version 1.6.0. Date de sortie cible : à déterminer .

Étapes de pré-version

• [ ] examiner et (fusionner ou supprimer) ouvrir les PR dans le jalon

Étapes de libération

• Branche [x] : à partir de develop , coupez une branche de version nommée release/1.6.0 pour vos modifications.
• [x] Version bump : indiquez le numéro de version dans distributor.php , distributor.pot et readme.txt s'il ne reflète pas déjà la version en cours de publication. Dans distributor.php mettez à jour à la fois la propriété du plugin "Version:" et la constante DT_VERSION du plugin, en vous assurant qu'elle est suffixée avec -dev .
• [x] Changelog : Ajout/mise à jour du changelog dans CHANGELOG.md .
• [x] Accessoires : mettez CREDITS.md jour le fichier
• [x] Mises à jour du fichier Lisez-moi : apportez toute autre modification au fichier Lisez-moi si nécessaire. README.md est orienté vers GitHub et readme.txt contient du contenu spécifique à WordPress.org. Les deux sont légèrement différents.
• [x] Traductions : Mettez à jour le fichier .pot en exécutant npm run makepot .
• [x] Fusion : effectuez une fusion non rapide de votre branche de publication vers develop (ou fusionnez la demande d'extraction), puis faites de même pour develop dans master ( git checkout master && git merge --no-ff develop ). master contient la version de développement stable.
• [x] Build : dans la branche master , exécutez npm install && npm run release . Cela créera un sous-dossier appelé release dans lequel la branche stable clonée en tant qu'arbre de travail et les dernières modifications seront copiées. Assurez-vous que tous les nouveaux fichiers se trouvent dans le dossier release ; sinon, vous devrez peut-être les ajouter à gulp-tasks/copy.js .
• [x] Vérifier : Y a-t-il des fichiers modifiés dans master ? Si tel est le cas, retournez à develop , exécutez toutes les tâches nécessaires et validez ces modifications avant de revenir à l'étape 6.
• [x] Test : passez à l'exécution de Distributor à partir de la version du sous-dossier release et exécutez quelques tâches courantes dans l'interface utilisateur pour garantir la fonctionnalité.
• [x] Push : Premier maître : git push , puis à partir du répertoire release , ajoutez tous les fichiers et envoyez-les à origin stable : git push origin stable .
• [x] Release : créez une nouvelle version , en nommant la balise et la version avec le nouveau numéro de version, et en ciblant la branche stable . Collez le journal des modifications de CHANGELOG.md dans le corps de la version et incluez un lien vers les problèmes fermés du jalon 1.6.0 . La version devrait maintenant apparaître sous les versions .
• [ ] Version bump (encore) : dans la branche develop ( cd ../ && git checkout develop ) bump le numéro de version dans distributor.php , distributor.pot et readme.txt à 1.6.1-dev . Ce n'est pas grave si la prochaine version peut avoir un numéro de version différent ; ce changement peut être géré juste avant la publication dans la première étape, comme cela peut également être le cas avec les annotations @since .
• [x] Fermer le jalon : modifiez le jalon 1.6.0 avec la date de sortie (dans le champ Due date (optional) ) et créez un lien vers la version GitHub (dans le Description field ), puis fermez le jalon.
• [x] Punt éléments incomplets : si des problèmes ouverts ou des PR qui ont été jalonnés pour 1.6.0 n'apparaissent pas dans la version, mettez à jour leur jalon à 2.0.0 ou Future Release .

Étapes après la publication

• [ ] soumettre le distributeur à Packagist (voir #356)