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

1. Confirm the version, target maintenance branch, scope, intended WordPress and PHP compatibility, and whether the release includes a database change.
2. Review every change since the previous tag. Prepare the changelog, upgrade notice, release-page copy, contributor credits, and any compatibility notes.
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. Update trunk’s stable-release metadata without replacing trunk’s next-development plugin version.
10. 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.

2. Test and build the exact candidate

1. Run the focused tests for every changed behavior, then the applicable full PHPUnit, multisite, BuddyPress, PHP coding standards, JavaScript, CSS, and text-domain checks.
2. Confirm the relevant GitHub Actions runs are green. Inspect experimental failures even when the workflow allows them.
3. Build from a clean canonical maintenance-branch working copy or export. The build requires the declared Node dependencies, PHP, WP-CLI with wp i18n, and the PHP mbstring extension.

npm ci
npx grunt release

4. Review all build warnings and confirm that the build did not leave unexplained source changes.
5. 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.
6. Confirm that source-only files are excluded, including tests, GitHub configuration, package metadata, the Gruntfile, and SCSS sources.
7. Create a ZIP with one top-level bbpress/ directory. Run unzip -t and compare its file manifest with the previous public release.
8. 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.
9. Exercise behavior changed by the release and record the final candidate checksum.

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.

3. Commit and tag the canonical source

1. Update the clean maintenance-branch working copy. Review svn status, svn diff, and every added or deleted path.
2. Commit the approved version and release-note changes to the canonical Subversion maintenance branch. Immediately inspect the resulting log message and record the revision.
3. Create the canonical source tag with svn copy from that exact recorded branch revision.
4. Commit the reviewed trunk stable-tag and release-metadata update.
5. Verify the maintenance branch, trunk, and canonical tag URLs. Do not create or repair the corresponding GitHub refs manually.

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. Confirm every canonical and deployment working copy is clean. Remove temporary checkouts, credentials, test databases, and build artifacts.
4. 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.
5. 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.