Distributor: リリースバージョン1.6.0

この問題は、1.6.0リリースの変更を追跡するためのものです。 発売予定日：未定。

プレリリース手順

• []マイルストーンでPRを確認して（マージまたはパント）

リリース手順

• [x]ブランチ： developから始めて、変更のためにrelease/1.6.0という名前のリリースブランチを切り取ります。
• [x]バージョンバンプ：リリースされているバージョンがまだ反映されていない場合は、バージョン番号をdistributor.php 、 distributor.pot 、およびreadme.txtバンプします。 distributor.php 、プラグインの「Version：」プロパティとプラグインのDT_VERSION定数の両方を更新し、接尾辞が-devます。
• [x]変更ログ： CHANGELOG.mdログを追加/更新します。
• [x]小道具： CREDITS.mdファイルを新しい寄稿者で更新し、メンテナが正確であることを確認します。
• [x] Readmeの更新：必要に応じて、その他のReadmeの変更を行います。 README.mdはGitHubを対象としており、 readme.txtはWordPress.org固有のコンテンツが含まれています。 2つはわずかに異なります。
• [x]翻訳： npm run makepot実行して、 .potファイルを更新します。
• [x]マージ：リリースブランチからdevelopへの非早送りマージ（またはプルリクエストのマージ）を行い、次にdevelopからmaster同じことを行います（ git checkout master && git merge --no-ff develop ）。 masterは、安定した開発バージョンが含まれています。
• [x]ビルド： masterブランチで、 npm install && npm run releaseます。 これにより、 releaseというサブフォルダーが作成され、 stableブランチがワークツリーとして複製され、最新の変更がコピーされます。 新しいファイルがreleaseフォルダーにあることを確認します。 そうでない場合は、それらをgulp-tasks/copy.jsに追加する必要があります。
• [x]チェック： master変更されたファイルはありますか？ その場合は、 developに戻り、必要なすべてのタスクを実行してそれらの変更をコミットしてから、ステップ6に戻ります。
• [x]テスト： releaseサブフォルダー内のバージョンから実行中のディストリビューターに切り替え、UIでいくつかの一般的なタスクを実行して、機能を確認します。
• [x]プッシュ：最初のマスター： git push 、次にreleaseディレクトリ内から、すべてのファイルを追加してorigin stable ： git push origin stableプッシュします。
• [x]リリース：新しいリリースを作成し、タグとリリースに新しいバージョン番号で名前を付け、 stableブランチをターゲットにします。 変更ログをCHANGELOG.mdからリリースの本文に貼り付け、 1.6.0マイルストーンのクローズされた問題へのリンクを含めます。 これで、リリースがリリースの下に表示されます。
• []バージョンバンプ（再び）： developブランチ（ cd ../ && git checkout develop ）で、バージョン番号をdistributor.php 、 distributor.pot 、およびreadme.txtバンプします。 1.6.1-dev 。 次のリリースが別のバージョン番号である可能性がある場合は問題ありません。 その変更は、 @sinceアノテーションの場合と同様に、最初のステップでリリースの直前に処理できます。
• [x]マイルストーンを閉じる： 1.6.0マイルストーンをリリース日（ Due date (optional)フィールド）で編集し、GitHubリリース（ Description field ）にリンクしてから、マイルストーンを閉じます。
• [x]不完全なアイテムのパント： 1.6.0マイルストーンされた未解決の問題またはPRがリリースに含まれない場合は、マイルストーンを2.0.0またはFuture Releaseに更新します。

リリース後の手順

• []ディストリビューターをPackagistに送信します（＃356を参照）