bbPress Codex

Prelaunch Checklist

Releasing bbPress involves several distinct systems. This checklist keeps the canonical source, release package, WordPress.org deployment, public documentation, and GitHub mirror in agreement.

Use clean, separate working copies and keep a release log. Record every Subversion revision, tag URL, ZIP checksum, test result, public URL, and manual approval as the release progresses.

Repository roles

• Canonical source: bbpress.svn.wordpress.org. All source commits, maintenance branches, and source tags originate here.
• Engineering mirror: GitHub. Use it for pull requests, review, and continuous integration. Do not push authoritative branches or tags directly to it.
• Issue tracker: bbPress Trac. Trac remains the public system of record for tickets and milestones.
• Deployment repository: plugins.svn.wordpress.org/bbpress. It contains built WordPress.org packages only and is not a development source.
• Translations: translate.wordpress.org/projects/wp-plugins/bbpress.

1. Prepare the release metadata

1. Confirm the version, target maintenance branch, scope, intended WordPress and PHP compatibility, and whether the release includes a database change.
2. Compare CHANGELOG.md with the previous canonical source tag. Never place a change committed after that tag beneath the tagged version. Explain every older-section difference with a recorded forward correction, audit the exact post-tag revision range and Trac milestone, put every notable post-tag change under the new release, remove duplicates, add the planned release links, and leave a fresh Unreleased section.
3. Confirm that every intended fix is present in the maintenance branch. A trunk commit is not automatically part of a maintenance release.
4. Update the plugin versions in bbpress.php and src/bbpress.php, including the runtime version in src/bbpress.php.
5. Update the version in package.json and the root package metadata in package-lock.json.
6. Update src/readme.txt: Stable tag, Tested up to, changelog, and upgrade notice.
7. Change the database version only when the release includes a schema or migration change. Do not bump it for an ordinary code release.
8. Run php tests/ci/check-versions.php and resolve every mismatch.
9. For a new major or minor line, create its canonical maintenance branch from the exact reviewed trunk revision. Patch releases use the existing maintenance branch.
10. Review the complete maintenance-branch diff and proposed log message. Do not commit or tag while any release-note, metadata, compatibility, credit, link, or scope question remains unresolved.

2. Test and commit the maintenance revision

1. Run the focused tests for every changed behavior against the final maintenance-branch diff, then the applicable full PHPUnit, multisite, BuddyPress, PHP coding standards, JavaScript, CSS, text-domain, version, and revision-annotation checks.
2. Confirm the relevant GitHub Actions runs are green. Inspect experimental failures even when the workflow allows them.
3. Run a pre-commit release build and inspect its warnings, package shape, translation template, and any tracked source changes.
4. Recheck svn status, the complete diff, every added or deleted path, and the proposed log message after testing and building.
5. Obtain explicit approval for that exact maintenance-branch diff and message, commit them to canonical Subversion, inspect the stored log, and record the exact revision.
6. Confirm the committed maintenance working copy is clean and that its version metadata and changelog still match the reviewed state.

3. Build, verify, and create the immutable source tag

1. Update or export a clean maintenance-branch working copy at the exact recorded revision. Confirm that it has no local changes.
2. Build from that exact recorded maintenance revision. The build requires the declared Node dependencies, PHP, WP-CLI with wp i18n, and the PHP mbstring extension.

npm ci
npx grunt release

3. Review all build warnings and confirm that the build did not leave unexplained source changes.
4. Confirm that build/bbpress.php, build/readme.txt, and a non-empty build/bbpress.pot exist. The POT must include strings from PHP, JavaScript, and block metadata.
5. Confirm that source-only files are excluded, including tests, GitHub configuration, package metadata, the Gruntfile, and SCSS sources.
6. Create a ZIP with one top-level bbpress/ directory. Run unzip -t and compare its file manifest with the previous public release.
7. Install the exact prospective ZIP into a clean WordPress site. Activate bbPress and test the Plugins screen, Forums administration, settings, permalinks, and a front-end forum, topic, and reply using a known-compatible theme.
8. Exercise behavior changed by the release and record the final candidate checksum.
9. Complete the immutable-tag gate. Reconfirm the exact branch revision and stored log; version, stable tag, release date, compatibility and database metadata; changelog boundary, release links, contributor credits, and upgrade notice; package manifest, POT, checksum, and smoke-test evidence; and every recorded approval. Stop if anything is incomplete, inconsistent, or uncertain.
10. Present the exact source revision, target tag URL, and tag message for explicit approval. A canonical Subversion release tag is permanent and can be created only once. It must never be modified, deleted, or recreated.
11. Create the canonical source tag with one svn copy from the approved branch revision.
12. Verify the tag’s copy origin, assigned revision, stored log, complete tree, version metadata, and byte-for-byte equality with the approved branch revision.
13. Update trunk’s stable-release metadata from the finalized maintenance changelog without replacing trunk’s next-development plugin version.
14. Verify the maintenance branch, trunk, and canonical tag URLs. Do not create or repair the corresponding GitHub refs manually.

The GitHub Build and Smoke Test workflow provides useful release evidence and uploads a candidate ZIP artifact. It does not authorize or perform a release.

4. Deploy to the WordPress.org Plugin Directory

1. Update a clean checkout of Plugin SVN.
2. Sync only the verified build/ contents to the matching deployment maintenance branch. Review additions, modifications, and deletions before committing.
3. Create the deployment tag from that exact reviewed branch state.
4. Sync the same current package to deployment trunk, including the stable tag in readme.txt, and review the complete diff.
5. Commit each approved deployment step separately when practical and record every revision.

Plugin SVN is deployment-only. Never use it as the source for a later development or release change.

5. Verify the live release

1. Confirm the WordPress.org plugin page and API report the new stable version.
2. Download the public ZIP. Compare its checksum and file manifest with the verified candidate.
3. Install or update from the public ZIP, activate bbPress, and render a real front-end forum.
4. Confirm Translate WordPress recognizes the release source and that the bundled bbpress.pot is present.
5. After the normal mirror interval, confirm GitHub’s trunk, maintenance branch, and tag resolve to the expected canonical Subversion changes. Check all Actions runs.

If a GitHub ref is delayed or missing, verify canonical Subversion and escalate the mirror problem. Do not repair the mirror by pushing directly to GitHub.

6. Publish release communications

1. Publish the version page in the bbPress Codex.
2. Add the version, date, canonical revision, and links to the Codex Releases table.
3. Publish the bbPress.org release post with links to the plugin page, download, and release notes.
4. Update the bbPress.org Downloads page.
5. Publish a support-forum announcement when the release warrants one.
6. Preview each edit before publishing and review each live page afterward.

The retired development blog at bbpdevel.wordpress.com is not a required release channel.

7. Finish and document

1. Return trunk to the next development version when necessary while retaining the new stable-release metadata.
2. Set the maintenance branch’s next patch-development version when that is the active project convention.
3. Close the released milestone in bbPress Trac with the actual release completion date after reviewing or moving any unresolved tickets.
4. Add the released version in Trac with the actual release date so tickets can identify the affected version.
5. Create the next maintenance milestone in Trac and assign deferred or newly discovered issues to it.
6. Confirm every canonical and deployment working copy is clean. Remove temporary checkouts, credentials, test databases, and build artifacts.
7. Complete the release log with canonical source, source tag, deployment branch, deployment tag, and deployment trunk revisions; public URLs; candidate and public ZIP checksums; tests; mirror status; and follow-up work.
8. If rollback is required, identify the last known-good canonical and deployment revisions before making another public change.

Translation strings

• bbPress translations are managed in GlotPress on Translate WordPress.
• The release build generates build/bbpress.pot from the built package with wp i18n make-pot.
• The bundled POT remains useful for offline and third-party translation workflows.
• The former bbpress-i18n.svn.wordpress.org POT is obsolete and is not a release source.

Automation boundary

Automation should validate versions, run tests and linting, build the package, inspect the POT and package manifest, install and smoke-test the candidate ZIP, calculate checksums, and prepare release records. Canonical tagging, WordPress.org deployment, and public publication retain an explicit maintainer approval gate.

A release is complete only after the canonical source, deployed package, public ZIP, documentation, translations, GitHub mirror, and clean working-copy state have each been verified.