Distributor: Release-Version 1.6.0

Dieses Problem betrifft die Nachverfolgung von Änderungen für die Version 1.6.0. Angestrebtes Veröffentlichungsdatum: TBD .

Schritte vor der Veröffentlichung

• [ ] PRs im Meilenstein überprüfen und (zusammenführen oder punktieren)

Freigabeschritte

• [x] Branch: Schneiden Sie ausgehend von develop einen Release-Branch namens release/1.6.0 für Ihre Änderungen aus.
• [x] Versions-Bump: Verbessere die Versionsnummer in distributor.php , distributor.pot und readme.txt wenn sie nicht bereits die veröffentlichte Version widerspiegelt. In distributor.php aktualisieren Sie sowohl die Plugin-Eigenschaft "Version:" als auch die Plugin-Konstante DT_VERSION und stellen Sie sicher, dass sie mit -dev angehängt ist.
• [x] Changelog: Füge das Changelog in CHANGELOG.md /aktualisiere es.
• [x] Requisiten: Aktualisieren Sie die CREDITS.md Datei mit allen neuen Mitwirkenden, bestätigen Sie, dass die Betreuer korrekt sind.
• [x] Readme-Updates: Nehmen Sie nach Bedarf weitere Readme-Änderungen vor. README.md ist auf GitHub ausgerichtet und readme.txt enthält WordPress.org-spezifische Inhalte. Die beiden sind etwas unterschiedlich.
• [x] Übersetzungen: Aktualisieren Sie die Datei .pot , indem Sie npm run makepot .
• [x] Merge: Führen Sie einen Non-Fast-Forward-Merge von Ihrem Release-Zweig zu develop (oder führen Sie den Pull-Request zusammen), dann machen Sie dasselbe für develop in master ( git checkout master && git merge --no-ff develop ). master enthält die stabile Entwicklungsversion.
• [x] Build: Führen Sie im Zweig master npm install && npm run release . Dadurch wird ein Unterordner namens release in den der Zweig stable als Arbeitsbaum geklont und die letzten Änderungen kopiert werden. Stellen Sie sicher, dass sich alle neuen Dateien im Ordner release ; Wenn nicht, müssen Sie sie möglicherweise zu gulp-tasks/copy.js hinzufügen.
• [x] Check: Gibt es modifizierte Dateien in master ? Wenn ja, gehen Sie zurück zu develop , führen Sie alle erforderlichen Aufgaben aus und übernehmen Sie diese Änderungen, bevor Sie zu Schritt 6 zurückkehren.
• [x] Test: Wechseln Sie von der Version im Unterordner release zur Ausführung von Distributor und führen Sie einige allgemeine Aufgaben in der Benutzeroberfläche durch, um die Funktionalität sicherzustellen.
• [x] Push: Zuerst Master: git push , dann aus dem Verzeichnis release alle Dateien hinzufügen und nach origin stable schieben: git push origin stable .
• [x] Release: Erstellen Sie ein neues Release , benennen Sie das Tag und das Release mit der neuen Versionsnummer und zielen Sie auf den stable Zweig ab. Fügen Sie das Änderungsprotokoll von CHANGELOG.md in den Hauptteil der Veröffentlichung ein und fügen Sie einen Link zu den geschlossenen Problemen des Releases erscheinen.
• [ ] Versions-Bump (wieder): Im develop Zweig ( cd ../ && git checkout develop ) Bump die Versionsnummer in distributor.php , distributor.pot und readme.txt bis 1.6.1-dev . Es ist in Ordnung, wenn die nächste Version möglicherweise eine andere Versionsnummer hat; diese Änderung kann im ersten Schritt direkt vor der Freigabe behandelt werden, wie dies auch bei @since Annotationen der Fall sein kann.
• [x] Meilenstein schließen: Bearbeiten Sie den 1.6.0-Meilenstein mit dem Veröffentlichungsdatum (im Feld Due date (optional) ) und verlinken Sie zum GitHub-Release (im Description field ), schließen Sie dann den Meilenstein.
• [x] Punt unvollständige Elemente: Wenn offene Issues oder PRs, die für 1.6.0 Meilensteine ​​gesetzt wurden, es nicht in die Veröffentlichung schaffen, aktualisieren Sie ihren Meilenstein auf 2.0.0 oder Future Release .

Schritte nach der Veröffentlichung

• [ ] Distributor an Packagist senden (siehe #356)