-
Notifications
You must be signed in to change notification settings - Fork 4
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Merge pull request #905 from publishpress/release-v2.10.0
Release v2.10.0
- Loading branch information
Showing
107 changed files
with
9,281 additions
and
1,266 deletions.
There are no files selected for viewing
This file was deleted.
Oops, something went wrong.
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,73 @@ | ||
| # A set of files you probably don't want in your WordPress.org distribution | ||
| *.code-workspace | ||
| *.sql | ||
| *.tar.gz | ||
| *.zip | ||
| .DS_Store | ||
| .babelrc | ||
| .distignore | ||
| .editorconfig | ||
| .env.testing | ||
| .env.testing.dist | ||
| .env.testing.linux.dist | ||
| .env.testing.mac.dist | ||
| .eslintrc.js | ||
| .git | ||
| .gitattributes | ||
| .github | ||
| .gitignore | ||
| .idea | ||
| .php-cs-fixer.cache | ||
| .phpcs.xml | ||
| .phplint-cache | ||
| .phplint.yml | ||
| .rsync-filters-post-build | ||
| .rsync-filters-pro-build | ||
| .travis.yml | ||
| .vscode | ||
| .wordpress-org | ||
| /assets_wp | ||
| /dev-workspace | ||
| /dist | ||
| /version.txt | ||
| /webpack.config.js | ||
| /yarn.lock | ||
| CONTRIBUTING.md | ||
| Gruntfile.js | ||
| README-build.md | ||
| README.md | ||
| RoboFile.php | ||
| Thumbs.db | ||
| /assets/jsx | ||
| /assets_wp | ||
| bin | ||
| build.xml | ||
| builder | ||
| builder.yml | ||
| builder.yml.dist | ||
| codeception.dist.yml | ||
| composer.json | ||
| composer.lock | ||
| cs | ||
| cypress | ||
| cypress.json | ||
| /dist | ||
| jest.config.js | ||
| jest.config.ts | ||
| jsconfig.json | ||
| mix-manifest.json | ||
| node_modules | ||
| package-lock.json | ||
| package.json | ||
| phpcs.xml | ||
| phpunit.xml | ||
| psalm.xml | ||
| ray-dist.php | ||
| ray.php | ||
| screenshot-*.png | ||
| /scripts | ||
| tailwind.config.js | ||
| tests | ||
| /vendor | ||
| webpack.config.js | ||
| webpack.mix.js |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file was deleted.
Oops, something went wrong.
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -1,37 +1,43 @@ | ||
| --- | ||
| name: Release the Free version (team only) | ||
| about: Describes default checklist for the plugin's release process. | ||
| title: Release v[VERSION] | ||
| name: Release the Free Version (Team Only) | ||
| about: Default checklist for the plugin's release process. | ||
| title: Release PublishPress Capabilities v[VERSION] | ||
| labels: release | ||
| assignees: '' | ||
|
|
||
| --- | ||
|
|
||
| To release the Free plugin please make sure to check all the checkboxes below. | ||
| To release the Free plugin, ensure you complete all the tasks below. | ||
|
|
||
| ### Pre-release Checklist | ||
|
|
||
| - [ ] Create the release branch as `release-<version>` based on the development branch | ||
| - [ ] Make sure to directly merge or use Pull Requests to merge hotfixes or features branches into the release branch | ||
| - [ ] Run `composer update` and check if there is any relevant update. Check if you need to lock the current version for any dependency. The `--no-dev` argument is optional here, since the build script will make sure to run the build with that argument. | ||
| - [ ] Update the changelog - make sure all the changes are there with a user-friendly description and that the release date is correct | ||
| - [ ] Update the version number to the next stable version. Use `$ vendor/bin/robo version <version-number>` | ||
| - [ ] Commit the changes to the release branch | ||
| - [ ] Build the zip package using `$ vendor/bin/robo build`. It should create a package in the `./dist` dir. | ||
| - [ ] Send to the team for testing | ||
| - [ ] Create a release branch named `release-<version>` from the development branch. | ||
| - [ ] Review and merge all relevant Pull Requests into the release branch. | ||
| - [ ] Start a dev-workspace session. | ||
| - [ ] Execute `composer update` to update the root and lib vendors. | ||
| - [ ] Review the updated packages. Mention any production library updates in the changelog. | ||
| - [ ] Inspect GitHub's Dependabot warnings or Pull Requests for relevant issues. Resolve any false positives first, then fix and commit the remaining issues. | ||
| - [ ] If necessary, build JS files for production using `composer build:js` and commit the changes. | ||
| - [ ] Run a WP VIP scan with `composer check:phpcs` to ensure no warnings or errors greater than 5 exist. | ||
| - [ ] Update the `.pot` file executing `composer gen:pot` and include a note in the changelog. | ||
| - [ ] Especially for minor and patch releases, maintain backward compatibility for changes like renamed or moved classes, namespaces, functions, etc. Include deprecation comments and mention this in the changelog. Major releases may remove deprecated code, but always note this in the changelog. | ||
| - [ ] Revise the changelog to include all changes with user-friendly descriptions and ensure the release date is accurate. | ||
| - [ ] Update the version number in the main plugin file and `readme.txt`, adhering to specifications from our [tech documentation](https://rambleventures.slab.com/posts/version-numbers-58nmrk4b), and commit to the release branch. | ||
| - [ ] Confirm there are no uncommitted changes. | ||
| - [ ] Build the zip package with `composer build`, creating a new package in the `./dist` directory. | ||
| - [ ] Distribute the new package to the team for testing. | ||
|
|
||
| ### Release Checklist | ||
| - [ ] Create and merge a Pull Request for the release branch into the `main` branch. | ||
| - [ ] Merge the `main` branch into the `development` branch. | ||
| - [ ] Establish the GitHub release on the `main` branch with the correct tag. | ||
|
|
||
| - [ ] Create a Pull Request and merge the release branch it into the `master` branch | ||
| - [ ] Merge the `master` branch into the `development` branch | ||
| - [ ] Create the Github release (make sure it is based on the `master` branch and correct tag) | ||
|
|
||
| #### SVN Repo | ||
| - [ ] Cleanup the `trunk` directory. | ||
| - [ ] Unzip the built package and move files to the `trunk` | ||
| - [ ] Remove any eventual file that shouldn't be released in the package (if you find anything, make sure to create an issue to fix the build script) | ||
| - [ ] Look for new files `$ svn status | grep \?` and add them using `$ svn add <each_file_path>` | ||
| - [ ] Look for removed files `$ svn status | grep !` and remove them `$ svn rm <each_file_path>` | ||
| - [ ] Create the new tag `$ svn cp trunk tags/<version>` | ||
| - [ ] Commit the changes `$ svn ci -m 'Releasing <version>'` | ||
| - [ ] Wait until WordPress updates the version number and make the final test updating the plugin in a staging site | ||
| #### WP SVN Deployment | ||
| - [ ] Navigate to the local copy of the SVN repo for the plugin. | ||
| - [ ] Update your working copy using `svn update`. | ||
| - [ ] Clear the `trunk` directory with `rm -rf trunk/*`. | ||
| - [ ] Unzip the built package and transfer files to the `trunk` folder. | ||
| - [ ] Remove any extraneous files (if found, create an issue to amend the `.rsync-filter-post-build` file). Keep only files really used on production. | ||
| - [ ] Find new files with `svn status | grep \?` and add them using `svn add <each_file_path>`. | ||
| - [ ] Identify removed files with `svn status | grep !` and delete them using `svn rm <each_file_path>`. | ||
| - [ ] Create the new tag using `svn cp trunk tags/<version>`. | ||
| - [ ] Commit the changes with `svn ci -m 'Releasing <version>'`. | ||
| - [ ] Await WordPress's version number update and perform a final test by updating the plugin on a staging site. |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -1,30 +1,38 @@ | ||
| --- | ||
| name: Release the Pro version (team only) | ||
| about: Describes default checklist for releasing the Pro plugin; | ||
| title: Release Pro v[VERSION] | ||
| name: Release the Pro Version (Team Only) | ||
| about: Default checklist for the plugin's release process. | ||
| title: Release PublishPress Capabilities Pro v[VERSION] | ||
| labels: release | ||
| assignees: '' | ||
|
|
||
| --- | ||
|
|
||
| To release the Pro plugin please make sure to check all the checkboxes below. | ||
| To release the Pro plugin, ensure you complete all the tasks below. | ||
|
|
||
| ### Pre-release Checklist | ||
|
|
||
| - [ ] Create the release branch as `release-<version>` based on the development branch | ||
| - [ ] Make sure to directly merge or use Pull Requests to merge hotfixes or features branches into the release branch | ||
| - [ ] Clone free version shared file to pro version | ||
| - [ ] Run `composer update` and check if there is any relevant update. Check if you need to lock the current version for any dependency. The `--no-dev` argument is optional here, since the build script will make sure to run the build with that argument. | ||
| - [ ] Update the changelog - make sure all the changes are there with a user-friendly description and that the release date is correct | ||
| - [ ] Update the version number to the next stable version. Use `$ vendor/bin/robo version <version-number>` | ||
| - [ ] Commit the changes to the release branch | ||
| - [ ] Build the zip package using `$ vendor/bin/robo build`. It should create a package in the `./dist` dir. | ||
| - [ ] Send to the team for testing | ||
| - [ ] Create a release branch named `release-<version>` from the development branch. | ||
| - [ ] Review and merge all relevant Pull Requests into the release branch. | ||
| - [ ] Start a dev-workspace session. | ||
| - [ ] Verify the correct version of the free plugin is referenced in the `lib/composer.json` file. Prefer stable versions. | ||
| - [ ] Execute `composer update` to update the root and lib vendors. | ||
| - [ ] Review the updated packages and mention any production library updates in the changelog. | ||
| - [ ] Check if all dependencies are synced from Free into the Pro plugin with `composer check:deps`. If required, merge dependencies using `composer fix:deps` and run `composer update` again. | ||
| - [ ] Check if the free plugin uses Composer's autoload and copy the autoload definition from the free plugin to the pro plugin refactoring the relative paths, on `/lib/composer.json`. Execute `composer dumpautoload` to update the autoload files. Commit the changes. | ||
| - [ ] Inspect GitHub's Dependabot warnings or Pull Requests for relevant issues. Resolve any false positives first, then fix and commit the remaining issues. | ||
| - [ ] If necessary, build JS files for production using `composer build:js` and commit the changes. | ||
| - [ ] Run a WP VIP scan with `composer check:phpcs` to ensure no warnings or errors greater than 5 exist. | ||
| - [ ] Update the `.pot` file executing `composer gen:pot` and include a note in the changelog. | ||
| - [ ] Especially for minor and patch releases, maintain backward compatibility for changes like renamed or moved classes, namespaces, functions, etc. Include deprecation comments and mention this in the changelog. Major releases may remove deprecated code, but always note this in the changelog. | ||
| - [ ] Revise the changelog to include all changes with user-friendly descriptions and ensure the release date is accurate. | ||
| -- [ ] Update the version number in the main plugin file and `readme.txt`, adhering to specifications from our [tech documentation](https://rambleventures.slab.com/posts/version-numbers-58nmrk4b), and commit to the release branch. | ||
| - [ ] Confirm there are no uncommitted changes. | ||
| - [ ] Build the zip package with `composer build`, creating a new package in the `./dist` directory. | ||
| - [ ] Distribute the new package to the team for testing. | ||
|
|
||
| ### Release Checklist | ||
| - [ ] Create and merge a Pull Request for the release branch into the `main` branch. | ||
| - [ ] Merge the `main` branch into the `development` branch. | ||
| - [ ] Establish the GitHub release on the `main` branch with the correct tag. | ||
|
|
||
| - [ ] Create a Pull Request and merge the release branch it into the `master` branch | ||
| - [ ] Merge the `master` branch into the `development` branch | ||
| - [ ] Create the Github release (make sure it is based on the `master` branch and correct tag) | ||
| - [ ] Update EDD registry and upload the new package | ||
| - [ ] Make the final test updating the plugin in a staging site | ||
| #### PublishPress.com Deployment | ||
| - [ ] Update the EDD registry on the Downloads menu, uploading the new package. | ||
| - [ ] Perform a final test by updating the plugin on a staging site. |
Oops, something went wrong.