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 관련 콘텐츠가 포함되어 있습니다. 둘은 약간 다릅니다.
• [x] 번역: npm run makepot 를 실행하여 .pot 파일을 업데이트합니다.
• [x] 병합: 릴리스 분기에서 develop 로 빠르게 감기가 아닌 병합을 수행한 다음(또는 pull 요청을 병합) develop 에 대해 동일한 작업을 master ( git checkout master && git merge --no-ff develop ). master 에는 안정적인 개발 버전이 포함되어 있습니다.
• [x] 빌드: master 분기에서 npm install && npm run release 합니다. 그러면 stable 분기가 작업 트리로 복제되고 최신 변경 사항이 복사된 release 라는 하위 폴더가 생성됩니다. 새 파일이 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 참조)