wpallstars/wp-fix-plugin-does-not-exist-notices
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases 15 Wiki Activity

Update release workflow documentation to reflect current best practices
Some checks failed
ci/woodpecker/push/woodpecker Pipeline failed
Details

Browse Source
This commit is contained in:
Marcus Quinn
2025-04-14 21:38:37 +01:00
parent c5d3c7672c
commit c73964888b
2 changed files with 145 additions and 108 deletions
Download Patch File Download Diff File Expand all files Collapse all files

107
.ai-assistant.md
View File

@ -70,11 +70,11 @@ We follow [Semantic Versioning](https://semver.org/):
### Version Update Checklist ### Version Update Checklist
When updating the version number, always update these files: When updating the version number, always update these files:
1. `wp-fix-plugin-does-not-exist-notices.php` (Plugin header) 1. `wp-fix-plugin-does-not-exist-notices.php` (Plugin header and version parameter in Plugin class initialization)
2. `CHANGELOG.md` (Add new version section) 2. `CHANGELOG.md` (Add new version section)
3. `readme.txt` (Stable tag and Changelog section) 3. `readme.txt` (Stable tag and Changelog section)
4. `README.md` (Update Changelog section to match readme.txt) 4. `README.md` (Update Changelog section to match readme.txt)
5. Update `FPDEN_VERSION` constant in the main plugin file 5. Update any JavaScript files that contain version constants (e.g., `admin/js/version-fix.js`)
6. Update `languages/wp-fix-plugin-does-not-exist-notices.pot` (Project-Id-Version and POT-Creation-Date) 6. Update `languages/wp-fix-plugin-does-not-exist-notices.pot` (Project-Id-Version and POT-Creation-Date)
**IMPORTANT**: Always ensure README.md is kept in sync with readme.txt for consistency across platforms. **IMPORTANT**: Always ensure README.md is kept in sync with readme.txt for consistency across platforms.
@ -106,50 +106,55 @@ Before creating a new release, verify the following:
### Release Process ### Release Process
1. Create a new branch for the version: `git checkout -b v{MAJOR}.{MINOR}.{PATCH}` 1. Create a new branch for the version: `git checkout -b v{MAJOR}.{MINOR}.{PATCH}` or use an existing feature branch
2. Update version numbers in ALL required files: 2. Update version numbers in ALL required files:
- `wp-fix-plugin-does-not-exist-notices.php` (Plugin header) - `wp-fix-plugin-does-not-exist-notices.php` (Plugin header and version parameter in Plugin class initialization)
- `FPDEN_VERSION` constant in the main plugin file - `readme.txt` (Stable tag and Changelog section)
- `readme.txt` (Stable tag) - `CHANGELOG.md` (Add new version section at the top)
- `README.md` (Ensure changelog is updated) - Any JavaScript files with version constants (e.g., `admin/js/version-fix.js`)
- `languages/wp-fix-plugin-does-not-exist-notices.pot` (Project-Id-Version) - `languages/wp-fix-plugin-does-not-exist-notices.pot` (Project-Id-Version)
- Any other files that reference the version number 3. Run the build script to create the plugin ZIP file and deploy to local testing environment:
3. Update CHANGELOG.md with all changes ```
4. Update readme.txt changelog section ./build.sh {MAJOR}.{MINOR}.{PATCH}
5. Update README.md changelog section to match readme.txt ```
6. Commit changes: `git commit -m "Prepare release v{MAJOR}.{MINOR}.{PATCH}"` 4. Test the plugin thoroughly in the local WordPress environment
7. Test changes locally on the version branch 5. Commit changes: `git commit -m "Version {MAJOR}.{MINOR}.{PATCH} - Brief description of changes"`
8. When satisfied with testing, merge to main: 6. Create a tag for the new version:
```
git tag -a v{MAJOR}.{MINOR}.{PATCH} -m "Version {MAJOR}.{MINOR}.{PATCH} - Brief description of changes"
```
7. Push the branch and tag to all remotes:
```
git push github feature/branch-name
git push gitea feature/branch-name
git push github v{MAJOR}.{MINOR}.{PATCH}
git push gitea v{MAJOR}.{MINOR}.{PATCH}
```
8. Verify the GitHub release is created with the ZIP file attached
9. When ready to merge to main, create a pull request or merge directly:
``` ```
git checkout main git checkout main
git merge v{MAJOR}.{MINOR}.{PATCH} --no-ff git merge feature/branch-name --no-ff
```
9. Push main to all remotes:
```
git push github main git push github main
git push gitea main git push gitea main
``` ```
10. Create and push a tag to trigger the GitHub Actions workflow:
```
git tag -a v{MAJOR}.{MINOR}.{PATCH} -m "Release version {MAJOR}.{MINOR}.{PATCH}"
git push github refs/tags/v{MAJOR}.{MINOR}.{PATCH}
git push gitea refs/tags/v{MAJOR}.{MINOR}.{PATCH}
```
11. Verify the GitHub Actions workflow completes successfully
## Build Process ## Build Process
The build process is handled by `build.sh`: The build process is handled by `build.sh`:
1. Updates version numbers 1. Creates build directory
2. Installs composer dependencies 2. Installs composer dependencies
3. Copies files to build directory 3. Copies required files to build directory
4. Creates ZIP file 4. Creates ZIP file
5. Automatically deploys to local WordPress testing environment
To manually build the plugin: To build the plugin and deploy to local testing:
``` ```
./build.sh {MAJOR}.{MINOR}.{PATCH} ./build.sh {MAJOR}.{MINOR}.{PATCH}
``` ```
This will create a ZIP file named `wp-fix-plugin-does-not-exist-notices-{MAJOR}.{MINOR}.{PATCH}.zip` and deploy the plugin to your local WordPress testing environment.
## Remote Repositories ## Remote Repositories
The plugin is hosted on multiple repositories: The plugin is hosted on multiple repositories:
@ -205,37 +210,43 @@ cd ~/Local/plugin-testing/app/public
### Creating a New Release ### Creating a New Release
``` ```
# 1. Create a new branch # 1. Start from a feature branch or create a new branch
git checkout main git checkout feature/branch-name
git checkout -b v1.7.0 # or
git checkout -b feature/new-feature-name
# 2. Update version numbers in ALL required files # 2. Update version numbers in ALL required files
# - wp-fix-plugin-does-not-exist-notices.php # - wp-fix-plugin-does-not-exist-notices.php (header and class initialization)
# - CHANGELOG.md # - CHANGELOG.md
# - readme.txt # - readme.txt (Stable tag and Changelog section)
# - README.md # - Any JavaScript files with version constants
# - languages/wp-fix-plugin-does-not-exist-notices.pot # - languages/wp-fix-plugin-does-not-exist-notices.pot
# - FPDEN_VERSION constant
# 3. Commit changes # 3. Build and test locally
./build.sh 1.7.0
# Test in local WordPress environment
# 4. Commit changes
git add . git add .
git commit -m "Prepare release v1.7.0" git commit -m "Version 1.7.0 - Brief description of changes"
# 4. Test changes locally on the version branch # 5. Create a tag
# (Run tests, verify functionality) git tag -a v1.7.0 -m "Version 1.7.0 - Brief description of changes"
# 5. Merge to main when ready # 6. Push branch and tag to remotes
git push github feature/branch-name
git push gitea feature/branch-name
git push github v1.7.0
git push gitea v1.7.0
# 7. Verify GitHub release is created with ZIP file
# Check: https://github.com/wpallstars/wp-fix-plugin-does-not-exist-notices/releases
# 8. Merge to main when ready
git checkout main git checkout main
git merge v1.7.0 --no-ff git merge feature/branch-name --no-ff
# 6. Push main to remotes
git push github main git push github main
git push gitea main git push gitea main
# 7. Create and push tag
git tag -a v1.7.0 -m "Release version 1.7.0"
git push github refs/tags/v1.7.0
git push gitea refs/tags/v1.7.0
``` ```
### Adding a New Feature ### Adding a New Feature

146
.ai-workflows/release-process.md
View File

@ -21,15 +21,23 @@ Based on the changes made, determine the appropriate version increment:
## Release Steps ## Release Steps
### 1. Create a New Branch ### 1. Start from a Feature Branch or Create a New Branch
You can either use an existing feature branch or create a new branch specifically for the release:
```bash ```bash
# Option 1: Use existing feature branch
git checkout feature/branch-name
# Option 2: Create a new branch
git checkout -b v{MAJOR}.{MINOR}.{PATCH} git checkout -b v{MAJOR}.{MINOR}.{PATCH}
``` ```
Example: Example:
```bash ```bash
git checkout -b v1.7.0 git checkout feature/refactor-and-improvements
# or
git checkout -b v2.2.1
``` ```
### 2. Update Version Numbers ### 2. Update Version Numbers
@ -38,42 +46,49 @@ Update the version number in the following files:
#### a. Main Plugin File (wp-fix-plugin-does-not-exist-notices.php) #### a. Main Plugin File (wp-fix-plugin-does-not-exist-notices.php)
Update both the plugin header and the version parameter in the Plugin class initialization:
```php ```php
/** /**
* Plugin Name: Fix 'Plugin file does not exist.' Notices * Plugin Name: Fix 'Plugin file does not exist.' Notices
* Plugin URI: https://wordpress.org/plugins/fix-plugin-does-not-exist-notices/ * Plugin URI: https://www.wpallstars.com
* Description: Adds missing plugins to the plugins list with a "Remove Reference" link so you can permanently clean up invalid plugin entries and remove error notices. * Description: Adds missing plugins to your plugins list with a "Remove Notice" action link, allowing you to safely clean up invalid plugin references.
* Version: {MAJOR}.{MINOR}.{PATCH} * Version: {MAJOR}.{MINOR}.{PATCH}
* ... * ...
*/ */
// At the bottom of the file, update the version parameter:
new WPALLSTARS\FixPluginDoesNotExistNotices\Plugin(__FILE__, '{MAJOR}.{MINOR}.{PATCH}');
``` ```
Also update the FPDEN_VERSION constant: #### b. JavaScript Files with Version Constants
```php Check for any JavaScript files that contain version constants, such as `admin/js/version-fix.js`:
define( 'FPDEN_VERSION', '{MAJOR}.{MINOR}.{PATCH}' );
```javascript
// Current plugin version - this should match the version in the main plugin file
const CURRENT_VERSION = '{MAJOR}.{MINOR}.{PATCH}';
``` ```
#### b. CHANGELOG.md #### c. CHANGELOG.md
Add a new section at the top of the CHANGELOG.md file: Add a new section at the top of the CHANGELOG.md file:
```markdown ```markdown
## [{MAJOR}.{MINOR}.{PATCH}] - YYYY-MM-DD All notable changes to this project should be documented both here and in the main Readme files.
### Added
- New feature 1
- New feature 2
### Changed #### [{MAJOR}.{MINOR}.{PATCH}] - YYYY-MM-DD
#### Added/Changed/Fixed
- Change 1 - Change 1
- Change 2 - Change 2
- Change 3
### Fixed #### [{PREVIOUS_VERSION}] - YYYY-MM-DD
- Bug fix 1
- Bug fix 2
``` ```
#### c. POT File (languages/wp-fix-plugin-does-not-exist-notices.pot) Note: Use the `####` heading format for consistency with the existing CHANGELOG.md structure.
#### d. POT File (languages/wp-fix-plugin-does-not-exist-notices.pot)
Update the Project-Id-Version and POT-Creation-Date (IMPORTANT - don't forget this step!): Update the Project-Id-Version and POT-Creation-Date (IMPORTANT - don't forget this step!):
@ -84,7 +99,7 @@ Update the Project-Id-Version and POT-Creation-Date (IMPORTANT - don't forget th
Note: Always use the current date for POT-Creation-Date in the format YYYY-MM-DD. Note: Always use the current date for POT-Creation-Date in the format YYYY-MM-DD.
#### d. readme.txt #### e. readme.txt
Update the stable tag: Update the stable tag:
@ -96,73 +111,84 @@ Add a new entry to the changelog section:
``` ```
= {MAJOR}.{MINOR}.{PATCH} = = {MAJOR}.{MINOR}.{PATCH} =
* New feature 1
* New feature 2
* Change 1 * Change 1
* Change 2 * Change 2
* Fixed bug 1 * Change 3
* Fixed bug 2
``` ```
Update the upgrade notice section: ### 3. Build and Test Locally
``` Run the build script to create the plugin ZIP file and deploy to your local WordPress testing environment:
= {MAJOR}.{MINOR}.{PATCH} =
Brief description of the most important changes in this release
```
### 3. Commit Changes
```bash ```bash
git add wp-fix-plugin-does-not-exist-notices.php CHANGELOG.md readme.txt README.md languages/wp-fix-plugin-does-not-exist-notices.pot ./build.sh {MAJOR}.{MINOR}.{PATCH}
git commit -m "Prepare release v{MAJOR}.{MINOR}.{PATCH}"
``` ```
### 4. Test Changes Locally This will:
1. Create a build directory
Test the changes thoroughly on the version branch to ensure everything works as expected: 2. Install composer dependencies
3. Copy required files to the build directory
4. Create a ZIP file named `wp-fix-plugin-does-not-exist-notices-{MAJOR}.{MINOR}.{PATCH}.zip`
5. Deploy the plugin to your local WordPress testing environment
Test the plugin thoroughly in your local WordPress environment:
- Test with the latest WordPress version - Test with the latest WordPress version
- Test with PHP 7.0+ (minimum supported version)
- Verify all features work as expected - Verify all features work as expected
- Check for any PHP warnings or notices - Check for any PHP warnings or notices
- Test any specific changes made in this version
### 5. Merge to Main ### 4. Commit Changes
When satisfied with testing, merge the version branch to main: ```bash
git add wp-fix-plugin-does-not-exist-notices.php CHANGELOG.md readme.txt admin/js/version-fix.js languages/wp-fix-plugin-does-not-exist-notices.pot
git commit -m "Version {MAJOR}.{MINOR}.{PATCH} - Brief description of changes"
```
### 5. Create a Tag
```bash
git tag -a v{MAJOR}.{MINOR}.{PATCH} -m "Version {MAJOR}.{MINOR}.{PATCH} - Brief description of changes"
```
### 6. Push Branch and Tag to Remotes
```bash
# Push the branch
git push github feature/branch-name
git push gitea feature/branch-name
# Push the tag
git push github v{MAJOR}.{MINOR}.{PATCH}
git push gitea v{MAJOR}.{MINOR}.{PATCH}
```
### 7. Verify GitHub Release
Check that the GitHub release was created successfully with the ZIP file attached:
https://github.com/wpallstars/wp-fix-plugin-does-not-exist-notices/releases
If the release doesn't appear or doesn't have the ZIP file attached, check the GitHub Actions page:
https://github.com/wpallstars/wp-fix-plugin-does-not-exist-notices/actions
### 8. Merge to Main (When Ready)
When you're satisfied with the release, merge the feature branch to main:
```bash ```bash
git checkout main git checkout main
git merge v{MAJOR}.{MINOR}.{PATCH} --no-ff git merge feature/branch-name --no-ff
```
The `--no-ff` flag creates a merge commit even if a fast-forward merge is possible, which helps preserve the branch history.
### 6. Push Main to Remotes
```bash
git push github main git push github main
git push gitea main git push gitea main
``` ```
### 7. Create and Push Tag The `--no-ff` flag creates a merge commit even if a fast-forward merge is possible, which helps preserve the branch history.
```bash
git tag -a v{MAJOR}.{MINOR}.{PATCH} -m "Release version {MAJOR}.{MINOR}.{PATCH}"
git push github refs/tags/v{MAJOR}.{MINOR}.{PATCH}
git push gitea refs/tags/v{MAJOR}.{MINOR}.{PATCH}
```
### 8. Monitor GitHub Actions
Open the GitHub Actions page to monitor the build and deployment process:
https://github.com/wpallstars/wp-fix-plugin-does-not-exist-notices/actions
### 9. Verify Release ### 9. Verify Release
- [ ] Check that the GitHub release was created successfully - [ ] Check that the GitHub release was created successfully with the ZIP file attached
- [ ] Verify that the plugin was deployed to WordPress.org - [ ] Verify that the plugin was deployed to WordPress.org (if applicable)
- [ ] Test the plugin from WordPress.org to ensure it works correctly - [ ] Test the plugin from the GitHub release ZIP to ensure it works correctly
- [ ] Verify that Git Updater can detect and install the new version
## Testing Previous Versions ## Testing Previous Versions