You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: .github/ISSUE_TEMPLATE/release-checklist.md
+81-60Lines changed: 81 additions & 60 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -7,66 +7,87 @@ type: release
7
7
assignees: ''
8
8
---
9
9
10
-
# Free plugin
10
+
# Versioning
11
+
12
+
This project follows [Semantic Versioning](http://semver.org/) for version numbers. When planning the release, make sure to follow these guidelines:
13
+
14
+
- MAJOR version for incompatible API changes
15
+
- MINOR version for backwards-compatible functionality additions
16
+
- PATCH version for backwards-compatible bug fixes
17
+
- When referencing versions, always use the full version number (e.g., 4.7.0 instead of 4.7) to avoid ambiguity between a specific patch release and a set of releases.
18
+
19
+
# Checklists for the Free plugin
11
20
12
21
To release the Free plugin, please check all the checkboxes below.
13
22
14
-
## Pre-release Checklist
15
-
-[ ] Create the release branch as `release-<version>` based on the development branch.
16
-
-[ ] Run `composer update --no-dev --dry-run` and check for any relevant updates on any requirements. This won't change the code, just show a simulation of running the update command. Evaluate the need of releasing with this library updated, or if we can add that for the next release.
17
-
-[ ] If any update should be included on this release (from the previous step), run the update command. If needed, you can run it only for the specific dependency: `composer update the/lib:version-constraint`. Make sure to check compatibility with the plugin and what version we should be using. Check if you need to lock the current version for any dependency using exact version numbers instead of relative version constraints. Make sure to add any changes to dependencies to the changelog.
18
-
-[ ] Make sure to directly merge or use Pull Requests to merge hotfixes or feature branches into the release branch.
19
-
-[ ] Check Github's Dependabot warnings or pull requests, looking for any relevant report. Remove any false-positive first. Fix and commit the fix for the issues you find.
20
-
-[ ] Build JS files to production by running `composer build:js` and commit (if your plugin uses any compiled JS file).
21
-
-[ ] Build translation files by running `composer build:lang` and commit the changes. Mention this on the changelog.
22
-
-[ ] Run WP VIP scan to make sure no warnings or errors > 5 exists: `composer check`.
23
-
-[ ] Update the changelog - make sure all the changes are there with a user-friendly description and that the release date is correct.
24
-
-[ ] Update the version number to the next stable version in the main plugin file and `readme.txt`. Commit the changes to the release branch. You can use `composer set:version`.
25
-
-[ ] Commit the changes to the release branch.
26
-
-[ ] Build the zip package, running `composer build`. It should create a package in the `./dist` dir.
27
-
-[ ] Send the new package to the team for testing.
28
-
29
-
## Release Checklist
30
-
-[ ] Create a Pull Request and merge the release branch with squash into the `master` branch.
31
-
-[ ] Merge the `master` branch into the `development` branch.
32
-
-[ ] Create the GitHub release (make sure it is based on the `master` branch and correct tag). This will trigger a GitHub action for automatic deployment on the WordPress SVN repo.
33
-
34
-
## Post-release Checklist
35
-
36
-
-[ ] Follow the action's result on the [repository actions page](https://github.com/publishpress/publishpress-future/actions).
37
-
-[ ] Go to the [WordPress.org plugin page](https://wordpress.org/plugins/post-expirator/) double check the information confirming the release finished successfully.
38
-
-[ ] Make a final test by updating the plugin on a staging site.
39
-
40
-
41
-
# Pro plugin
42
-
43
-
## Pre-release Checklist
44
-
45
-
-[ ] Create the release branch as `release-<version>` based on the development branch.
46
-
-[ ] Run `composer update --no-dev --dry-run` and check if there is any relevant update on any requirement. This won't change the code, just show a simulation of running the update command. Evaluate the need to release with this library updated, or if we can add that for the next release.
47
-
-[ ] If any update should be included on this release (from the previous step), make sure to run the update command only for the specific dependency: `composer update the/lib:version-constraint`. Make sure to check compatibility with the plugin and what version we should be using. Check if you need to lock the current version for any dependency using exact version numbers instead of relative version constraints. Make sure to add any changes to dependencies to the changelog.
48
-
-[ ] Make sure to directly merge or use Pull Requests to merge hotfixes or feature branches into the release branch.
49
-
-[ ] Check Github's Dependabot warnings or pull requests, looking for any relevant report. Remove any false-positive first. Fix and commit the fix for the issues you find.
50
-
-[ ] Build JS files to production by running `composer build:js` and commit (if your plugin uses any compiled JS file).
51
-
-[ ] Build translation files by running `composer build:lang` and commit the changes. Mention this on the changelog.
52
-
-[ ] Run WP VIP scan to make sure no warnings or errors > 5 exists: `composer check`.
53
-
-[ ] Update the changelog - make sure all the changes are there with a user-friendly description and that the release date is correct.
54
-
-[ ] Update the version number to the next stable version in the main plugin file and `readme.txt`. Commit the changes to the release branch. You can use `composer set:version`.
55
-
-[ ] Commit the changes to the release branch.
56
-
-[ ] Build the zip package running `composer build`. It should create a package in the `./dist` dir.
57
-
-[ ] Send the new package to the team for testing.
58
-
59
-
## Release Checklist
60
-
61
-
-[ ] Create a Pull Request and merge the release branch with squash into the `master` branch.
62
-
-[ ] Merge the `master` branch into the `development` branch.
63
-
-[ ] Create the GitHub release (make sure it is based on the `master` branch and correct tag).
64
-
-[ ] Follow the action's result on the [repository actions page](https://github.com/publishpress/publishpress-future-pro/actions).
65
-
-[ ] Go to [PublishPress site admin panel](https://publishpress.com/wp-admin) > Downloads, locate "Future Pro", and edit:
66
-
-[ ] File URL on Download Files, uploading the new package to the media library.
67
-
-[ ] On Licensing, update the version number.
68
-
-[ ] On Licensing, update the changelog.
69
-
70
-
## Post-release Checklist
71
-
72
-
-[ ] Make the final test by updating the plugin on a staging site.
23
+
## Pre-release
24
+
25
+
-[ ] Create the release branch as `release-<version>` based on the development branch. Use the command: `git checkout -b release-<version> develop`.
26
+
-[ ] Merge any pending hotfixes or feature branches into the release branch using either direct merges or Pull Requests. Ensure all changes are properly reviewed and tested before merging.
27
+
-[ ] Review GitHub's Dependabot alerts and pull requests. Dismiss false positives and fix legitimate security issues.
28
+
-[ ] Run `composer build:js` to build JS files to production.
29
+
-[ ] Run `composer build:lang` to build translation files and commit the changes. Mention this on the changelog.
30
+
-[ ] Run `composer check` to run check the code and make sure no warnings or errors.
31
+
-[ ] Run `composer test Unit` to run the Unit tests and verify all tests pass successfully.
32
+
-[ ] Run `composer test Integration` to run Integration tests and verify all tests pass successfully.
33
+
-[ ] Run `composer set:version <version>` to update version numbers in plugin files.
34
+
-[ ] Update the changelog - ensure all changes are documented with clear, user-friendly descriptions. Verify the release date is accurate and the version number matches the release version. Include Pro features in the changelog, clearly marking them with `- PRO feature` or `- PRO` suffix to distinguish premium functionality from free features.
35
+
-[ ] Verify all changes are committed to the release branch and there are no uncommitted files or pending changes. Use `git status` to confirm the working directory is clean.
36
+
-[ ] Run `composer build` to build the zip package. It should create a package in the `./dist` directory.
37
+
-[ ] Send the new package to the team for testing and quality assurance review.
38
+
39
+
## Release
40
+
41
+
-[ ] Create a Pull Request from the release branch to the `master` branch, ensuring all changes are properly reviewed and approved before merging.
42
+
-[ ] Merge the Pull Request using squash merge to maintain a clean commit history on the `master` branch.
43
+
-[ ] Merge the `master` branch back into the `develop` branch to ensure development continues with the latest release changes.
44
+
-[ ] Create the GitHub release based on the `master` branch with the correct version tag (e.g., `4.7.0`). Include release notes summarizing key changes from the changelog. This will automatically trigger the GitHub action for deployment to the WordPress.org SVN repository.
45
+
-[ ] Monitor the GitHub Actions workflow progress on the [repository actions page](https://github.com/publishpress/publishpress-future/actions) to ensure the deployment to WordPress.org SVN repository completes successfully without errors.
46
+
-[ ] Visit the [WordPress.org plugin page](https://wordpress.org/plugins/post-expirator/) to verify the release was published successfully and all information is accurate.
47
+
48
+
## Post-release
49
+
50
+
-[ ] Perform final testing by updating the plugin on a staging site to verify the release works correctly in a real WordPress environment.
51
+
-[ ] Test key plugin functionality to ensure no regressions were introduced during the release process.
52
+
-[ ] Verify that the plugin version number displays correctly in the WordPress admin dashboard.
53
+
54
+
# Checklists for the Pro plugin
55
+
56
+
## Pre-release
57
+
58
+
-[ ] Create the release branch as `release-<version>` based on the development branch. Use the command: `git checkout -b release-<version> develop`.
59
+
-[ ] Merge any pending hotfixes or feature branches into the release branch using either direct merges or Pull Requests. Ensure all changes are properly reviewed and tested before merging.
60
+
-[ ] Review GitHub's Dependabot alerts and pull requests. Dismiss false positives and fix legitimate security issues.
61
+
-[ ] Update the reference for the `publishpress/publishpress-future` package in the `lib/composer.json` file to use the recently released version tag (e.g., `4.7.0`) instead of a branch reference. This ensures the Pro plugin uses the stable release of the Free plugin.
62
+
-[ ] Run `composer update` to ensure the free plugin dependency is updated to the latest version.
63
+
-[ ] Run `composer build:js` to build JS files to production.
64
+
-[ ] Run `composer build:lang` to build translation files and commit the changes. Mention this on the changelog.
65
+
-[ ] Run `composer check` to run check the code and make sure no warnings or errors.
66
+
-[ ] Run `composer test Unit` to run the Unit tests and verify all tests pass successfully.
67
+
-[ ] Run `composer test Integration` to run Integration tests and verify all tests pass successfully.
68
+
-[ ] Run `composer set:version <version>` to update version numbers in plugin files.
69
+
-[ ] Update the changelog - make sure all the changes are there with a user-friendly description, that the release date is correct, and that the version number matches the release version.
70
+
-[ ] Verify all changes are committed to the release branch and there are no uncommitted files or pending changes. Use `git status` to confirm the working directory is clean.
71
+
-[ ] Run `composer build` to build the zip package. It should create a package in the `./dist` directory.
72
+
-[ ] Send the new package to the team for testing and quality assurance review.
73
+
74
+
## Release
75
+
76
+
-[ ] Create a Pull Request from the release branch to the `master` branch, ensuring all changes are properly reviewed and approved before merging.
77
+
-[ ] Merge the Pull Request using squash merge to maintain a clean commit history on the `master` branch.
78
+
-[ ] Merge the `master` branch back into the `develop` branch to ensure development continues with the latest release changes.
79
+
-[ ] Create the GitHub release based on the `master` branch with the correct version tag (e.g., `4.7.0`). Include release notes summarizing key changes from the changelog.
80
+
-[ ] Monitor the GitHub Actions workflow progress on the [repository actions page](https://github.com/publishpress/publishpress-future-pro/actions) to ensure there is no error.
81
+
-[ ] Update the Pro plugin on the PublishPress website:
82
+
-[ ] Navigate to [PublishPress site admin panel](https://publishpress.com/wp-admin) > Downloads and locate "Future Pro".
83
+
-[ ] Upload the new package file to the media library and update the File URL in Download Files.
84
+
-[ ] Update the version number in the Licensing section to match the release version.
85
+
-[ ] Update the changelog in the Licensing section with the latest release notes.
86
+
-[ ] Save all changes and verify the download link works correctly.
87
+
88
+
## Post-release
89
+
90
+
-[ ] Perform final testing by updating the plugin on a staging site to verify the release works correctly in a real WordPress environment.
91
+
-[ ] Test key plugin functionality to ensure no regressions were introduced during the release process.
92
+
-[ ] Verify that the plugin version number displays correctly in the WordPress admin dashboard.
93
+
-[ ] Confirm that all Pro features are working as expected and license validation is functioning properly.
0 commit comments