Distributor: Versión de lanzamiento 1.6.0

Este problema es para realizar un seguimiento de los cambios de la versión 1.6.0. Fecha de lanzamiento prevista: TBD .

Pasos previos al lanzamiento

• [] revisar y (fusionar o despejar) RP abiertos en el hito

Pasos de liberación

• [x] Rama: a partir de develop , corte una rama de lanzamiento llamada release/1.6.0 para sus cambios.
• [x] Aumento de la versión: Aumente el número de versión en distributor.php , distributor.pot y readme.txt si aún no refleja la versión que se está lanzando. En distributor.php actualice la propiedad del complemento "Versión:" y el complemento DT_VERSION constante, asegurándose de que tenga el sufijo -dev .
• [x] Registro de cambios: agregue / actualice el registro de cambios en CHANGELOG.md .
• [x] Props: actualice el archivo CREDITS.md con los nuevos contribuyentes, confirme que los mantenedores sean precisos.
• [x] Actualizaciones del archivo Léame: realice cualquier otro cambio del archivo Léame según sea necesario. README.md está orientado a GitHub y readme.txt contiene contenido específico de WordPress.org. Los dos son ligeramente diferentes.
• [x] Traducciones: actualice el archivo .pot ejecutando npm run makepot .
• [x] Fusionar: haz una fusión que no sea de avance rápido desde tu rama de lanzamiento a develop (o fusiona la solicitud de extracción), luego haz lo mismo para develop en master ( git checkout master && git merge --no-ff develop ). master contiene la versión de desarrollo estable.
• [x] Compilación: en la rama master , ejecute npm install && npm run release . Esto creará una subcarpeta llamada release con la rama stable clonada en ella como un árbol de trabajo y copiando los últimos cambios. Asegúrese de que los archivos nuevos estén en la carpeta release ; de lo contrario, es posible que deba agregarlos a gulp-tasks/copy.js .
• [x] Verificar: ¿Hay archivos modificados en master ? Si es así, regrese a develop , ejecute todas las tareas necesarias y confirme esos cambios antes de regresar al Paso 6.
• [x] Prueba: cambie a Distribuidor en ejecución desde la versión en la subcarpeta release y ejecute algunas tareas comunes en la interfaz de usuario para garantizar la funcionalidad.
• [x] Empuje: Primero maestro: git push , luego desde dentro del directorio release , agregue todos los archivos y envíelos a origin stable : git push origin stable .
• [x] Lanzamiento: crea un nuevo lanzamiento , nombra la etiqueta y el lanzamiento con el nuevo número de versión, y apunta a la rama stable . Pegue el registro de cambios de CHANGELOG.md en el cuerpo de la versión e incluya un enlace a los problemas cerrados en el hito 1.6.0 . La versión debería aparecer ahora debajo de versiones .
• [] Aumento de la versión (nuevamente): en la rama develop ( cd ../ && git checkout develop ) aumente el número de versión en distributor.php , distributor.pot y readme.txt a 1.6.1-dev . Está bien si la próxima versión puede ser un número de versión diferente; ese cambio se puede manejar justo antes del lanzamiento en el primer paso, como también podría ser el caso con las anotaciones @since .
• [x] Cerrar hito: Edite el hito 1.6.0 con la fecha de lanzamiento (en el campo Due date (optional) ) y enlace a la publicación de GitHub (en el Description field ), luego cierre el hito.
• [x] Punt elementos incompletos: Si algún problema abierto o PR que se marcaron por 1.6.0 no se incluyen en el lanzamiento, actualice su hito a 2.0.0 o Future Release .

Pasos posteriores al lanzamiento

• [] enviar Distribuidor a Packagist (ver # 356)