Build assets during the release

.distignore

@@ -0,0 +1,41 @@
+/.git
+/.github
+/.wordpress-org
+/bin
+/config
+/docs
+/gulp-tasks
+/lang
+/tests
+/vendor/
+/node_modules
+
+/.babelrc
+/.browserslistrc
+/.editorconfig
+/.eslintignore
+/.eslintrc.js
+/.distignore
+/.gitignore
+/.travis.yml
+/.stylelintrc
+/CHANGELOG.md
+/CODE_OF_CONDUCT.md
+/composer.json
+/composer.lock
+/CONTRIBUTING.md
+/CREDITS.md
+/gulpfile.babel.js
+/hookdoc-conf.json
+/LICENSE.md
+/package.json
+/package-lock.json
+/phpcs.xml
+/phpunit.xml.dist
+/postcss.config.js
+/README.md
+/SECURITY.md
+/run-wpacceptance.sh
+/single-site.xml.dist
+/webpack.config.js
+/wpacceptance.json

.github/workflows/push-deploy.yml

@@ -1,17 +1,51 @@
-name: Deploy to WordPress.org
+name: Publish New Release
+
+env:
+  SLUG: "elasticpress"
+
 on:
-  push:
-    tags:
-    - "*"
+  release:
+    types: [published]
+
 jobs:
   tag:
-    name: New tag
+    name: New release
     runs-on: ubuntu-latest
     steps:
-    - uses: actions/checkout@master
+    - name: Checkout code
+      uses: actions/checkout@v2
+
+    - name: install node v10
+      uses: actions/setup-node@v1
+      with:
+        node-version: 10
+
+    - name: Build
+      run: |
+        npm install
+        npm run build
+
     - name: WordPress Plugin Deploy
+      if: "! github.event.release.prerelease"
+      id: deploy
       uses: 10up/action-wordpress-plugin-deploy@stable
       env:
-        SVN_PASSWORD: ${{ secrets.SVN_PASSWORD }}
         SVN_USERNAME: ${{ secrets.SVN_USERNAME }}
-        SLUG: elasticpress
+        SVN_PASSWORD: ${{ secrets.SVN_PASSWORD }}
+        SLUG: ${{ env.SLUG }}
+
+    - name: Create ZIP
+      run: |
+        TMP_DIR="${HOME}/archive/${{ env.SLUG }}"
+        mkdir -p $TMP_DIR
+        rsync -rc --exclude-from="${{ github.workspace }}/.distignore" "${{ github.workspace }}/" "$TMP_DIR/" && cd $TMP_DIR/.. && zip -r "${{ github.workspace }}/${{ env.SLUG }}.zip" .
+
+    - name: Upload release asset
+      uses: actions/upload-release-asset@v1
+      env:
+        GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
+      with:
+        upload_url: ${{ github.event.release.upload_url }}
+        asset_path: ${{ github.workspace }}/${{ env.SLUG }}.zip
+        asset_name: elasticpress-${{ github.ref_name }}.zip
+        asset_content_type: application/zip

.gitignore

@@ -1,5 +1,6 @@
 /vendor/
 node_modules
+/dist
 .idea
 .history
 docs-built

CONTRIBUTING.md

@@ -39,11 +39,30 @@ The `develop` branch is the development branch which means it contains the next
 1. Test: While still on the `master` branch, test for functionality locally.
 1. Push: Push your `master` branch to GitHub (e.g. `git push origin master`).
 1. Release: Create a [new release](https://github.com/10up/elasticpress/releases/new), naming the tag and the release with the new version number, and targeting the `master` branch.  Paste the release changelog from `CHANGELOG.md` into the body of the release and include a link to the closed issues on the [milestone](https://github.com/10up/elasticpress/milestone/#?closed=1).
+1. [Check the _Publish New Release_ action](https://github.com/10up/ElasticPress/actions/workflows/push-deploy.yml): After the release, GitHub should trigger an action to generate a zip with the plugin and attach it to the GitHub Release page.
 1. SVN: Wait for the [GitHub Action](https://github.com/10up/ElasticPress/actions?query=workflow%3A%22Deploy+to+WordPress.org%22) to finish deploying to the WordPress.org repository.  If all goes well, users with SVN commit access for that plugin will receive an emailed diff of changes.
 1. Check WordPress.org: Ensure that the changes are live on https://wordpress.org/plugins/elasticpress/.  This may take a few minutes.
 1. Close milestone: Edit the [milestone](https://github.com/10up/elasticpress/milestone/#) with release date (in the `Due date (optional)` field) and link to GitHub release (in the `Description` field), then close the milestone.
 1. Punt incomplete items: If any open issues or PRs which were milestoned for `X.Y.Z` do not make it into the release, update their milestone to `X.Y.Z+1`, `X.Y+1.0`, `X+1.0.0` or `Future Release`.
 
+## Pre-release instructions (betas, release candidates, etc)
+
+Pre-releases are different from normal versions because (1) they are not published on WordPress.org and (2) they are usually created from a branch different from `develop`.
+
+1. If the new version requires a reindex, add its number to the `$reindex_versions` array in the `ElasticPress\Upgrades::check_reindex_needed()` method.  If it is the case, remember to add that information to the Changelog listings in `readme.txt` and `CHANGELOG.md`.
+1. Branch: Starting from the next version branch, for example, `4.x.x`, cut a release branch named `release/X.Y.Z` for your changes.
+1. Version bump: Bump the version number in `elasticpress.php`, `package.json`, `package-lock.json`, `readme.txt`, and any other relevant files if it does not already reflect the version being released.  In `elasticpress.php` update both the plugin "Version:" property and the plugin `EP_VERSION` constant. The version should follow the `X.Y.Z-beta.A` pattern.
+1. Changelog: Add/update the changelog in `CHANGELOG.md` and `readme.txt`, ensuring to link the [X.Y.Z] release reference in the footer of `CHANGELOG.md` (e.g., https://github.com/10up/ElasticPress/compare/X.Y.Z-1...X.Y.Z).
+1. Props: Update `CREDITS.md` file with any new contributors, confirm maintainers are accurate.
+1. Readme updates: Make any other readme changes as necessary. `README.md` is geared toward GitHub and `readme.txt` contains WordPress.org-specific content.  The two are slightly different.
+1. New files: Check to be sure any new files/paths that are unnecessary in the production version are included in `.gitattributes`.
+1. Merge: Merge the release branch/PR into the next version branch (`4.x.x`, for example).
+1. Test: Checkout the next version branch locally and build assets like the GitHub Action will do (see `.github/workflows/push-deploy.yml`)
+1. Release: Create a [new pre-release](https://github.com/10up/elasticpress/releases/new), naming the tag and the release with the new version number, and targeting the next version branch branch.  Paste the release changelog from `CHANGELOG.md` into the body of the release and include a link to the closed issues on the [milestone](https://github.com/10up/elasticpress/milestone/#?closed=1). **ATTENTION**: Make sure to check the `This is a pre-release` checkbox, so the release is not published on WordPress.org.
+1. [Check the _Publish New Release_ action](https://github.com/10up/ElasticPress/actions/workflows/push-deploy.yml): After the release, GitHub should trigger an action to generate a zip with the plugin and attach it to the GitHub Release page.
+1. Close milestone: Edit the [milestone](https://github.com/10up/elasticpress/milestone/#) with release date (in the `Due date (optional)` field) and link to GitHub release (in the `Description` field), then close the milestone.
+1. Punt incomplete items: If any open issues or PRs which were milestoned for `X.Y.Z` do not make it into the release, update their milestone to `X.Y.Z+1`, `X.Y+1.0`, `X+1.0.0` or `Future Release`.
+
 ## Hotfix release instructions
 
 There may be cases where we have an urgent/important fix that ideally gets into a release quickly without any other changes (e.g., a "hotfix") so as to reduce (1) the amount or testing before being confident in the release and (2) to reduce the chance of unintended side effects from the extraneous non-urgent/important changes.  In cases where code has previously been merged into `develop` but that ideally is not part of a hotfix, the normal release instructions above will not suffice as they would release all code merged to `develop` alongside the intended urgent/important "hotfix" change(s).  In case of needing to release a "hotfix" the following are the recommended steps to take.