Distributor: 发布版本 1.6.0

此问题用于跟踪 1.6.0 版本的更改。 目标发布日期：待定。

预发布步骤

• [ ]在里程碑中审查和（合并或弃船）

发布步骤

• [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.md面向 GitHub， readme.txt包含特定于 WordPress.org 的内容。 两者略有不同。
• [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子文件夹中的版本切换到运行 Distributor，并在 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] Punt 不完整的项目：如果任何以1.6.0为里程碑的未解决问题或 PR 没有进入发布，请将其里程碑更新为2.0.0或Future Release 。

发布后步骤

• [ ] 将分销商提交给 Packagist（参见 #356）