Release Management

Release Cycle and Versioning

This project follows a disciplined release schedule to ensure consistent improvements to our WordPress environment. We prioritize stability while maintaining a high velocity of updates.

Release Cadence

Updates are pushed on a weekly basis. Each release consolidates the week's contributions, bug fixes, and performance enhancements. These updates are typically tagged and released every Friday.

Semantic Versioning

We adhere to Semantic Versioning 2.0.0. Version numbers follow the MAJOR.MINOR.PATCH format:

• MAJOR: Significant architectural changes or breaking changes to the WordPress core configuration or theme structure.
• MINOR: New features, new plugins, or substantial UI components added in a backward-compatible manner.
• PATCH: Weekly bug fixes, security patches, and minor adjustments.

Changelog Maintenance

Every release is accompanied by an entry in the CHANGELOG.md file located in the root directory. We follow the Keep a Changelog convention to ensure readability.

Each entry categorizes changes as follows:

• Added: For new features or plugins.
• Changed: For changes in existing functionality.
• Deprecated: For soon-to-be-removed features.
• Removed: For features removed in this release.
• Fixed: For any bug fixes.
• Security: In case of vulnerabilities or dependency updates.

Accessing Releases

Users can track updates through GitHub Releases or by checking out specific Git tags.

Using Git Tags

To switch to a specific version of the project, use the following commands:

# Fetch the latest tags from the repository
git fetch --tags

# List all available versions
git tag -l

# Checkout a specific version (e.g., v1.2.0)
git checkout v1.2.0

GitHub Releases

Each weekly update is packaged as a GitHub Release. These releases include:

• A summary of the changelog for that version.
• Source code archives (ZIP and tar.gz).
• Direct links to relevant pull requests included in the release.

Environment Promotion

To ensure stability, updates move through the following stages before reaching the public-facing release:

1. Development: Active work and weekly contributions.
2. Staging: Automated testing and manual QA of the week's changes.
3. Production (Release): Final merge into the main branch and version tagging.

Users are encouraged to use the latest Tagged Release for production environments rather than tracking the main branch directly to avoid unverified mid-week changes.