Skip to content

Release Guide

Jump to bottom
jacobd edited this page Jun 9, 2026 · 3 revisions

Releasing Post and Page Builder

This plugin is released to two channels:

  1. WordPress.org — the public plugin repository (SVN).
  2. GitHub Releases — a tagged release with the built .zip attached.

Both are driven by Travis CI when you push a git tag. There are no GitHub Actions workflows in this repo — Travis is the only CI/release engine.

A third, manual step finalizes delivery on the BoldGrid Central update channel (separate from WordPress.org), via an internal management portal owned by the BoldGrid/release team.

TL;DR

# 1. Make sure the version bump + changelog are merged to master and master is green.
# 2. Tag the release commit with the BARE version number (no "v" prefix):
git tag -a 1.27.11 -m "Release 1.27.11"
git push origin 1.27.11
# 3. Watch the Travis build for the tag.
# 4. Verify on WordPress.org and edit the GitHub release notes.
# 5. Finalize on the BoldGrid Central portal (release team).

The tag name must equal the version in readme.txt → Stable tag: and the plugin header Version: (e.g. 1.27.11). WordPress.org serves whatever Stable tag: points to.

Prerequisites (one-time / verify)

  • Travis CI is active for BoldGrid/post-and-page-builder.
  • These secrets exist as encrypted Travis environment variables:
    • WP_USERNAME / WP_PASSWORD — WordPress.org SVN credentials.
    • GITHUB_TOKEN — used to create the GitHub release and upload the zip.
    • WP_SVN_REPO — the WordPress.org SVN URL for this plugin.

If any of these are rotated/expired, the deploy fails (often silently from the author's point of view) — always confirm the result on WordPress.org.

Step 1 — Bump the version (before tagging)

All of these must agree on the new X.Y.Z:

File What to change
post-and-page-builder.php Version: header (this also feeds BOLDGRID_EDITOR_VERSION)
readme.txt Stable tag:
readme.txt Add a new = X.Y.Z = entry under == Changelog ==
package.json version — cosmetic only (stripped before SVN), but keep it in sync

Notes:

  • WordPress.org determines the served version from readme.txt → Stable tag:. The header Version: should match it.
  • You can ship multiple changelog entries under one tag. If 1.27.10 and 1.27.11 were both merged but only 1.27.11 is tagged, both changelog entries ship and the served version is 1.27.11.

Merge the bump + changelog to master before tagging.

Step 2 — Tag and push

git tag -a X.Y.Z -m "Release X.Y.Z"
git push origin X.Y.Z
  • Bare semver, no v prefix — the deploy script uses the tag name verbatim as the SVN tag directory name (tags/X.Y.Z). Existing tags: 1.27.9, 1.27.10, …
  • Pre-release / RC tags have been used too (e.g. 1.27.1-rc.1).
  • Pushing the tag is what triggers everything. It starts a live public release.

Step 3 — What Travis does automatically

From .travis.yml, the deploy: block runs only on tag builds and only on PHP 7.4. It has two steps:

  1. provider: script → WordPress.org SVN push. Runs @boldgrid/wordpress-tag-sync/release.sh, which:
    • derives VERSION from the git tag (git describe --exact-match --tags),
    • svn cp trunk → tags/VERSION, then replaces it with the current repo files,
    • strips dev files (see below),
    • svn commits to WordPress.org using WP_USERNAME / WP_PASSWORD,
    • builds post-and-page-builder.zip.
  2. provider: releases → GitHub Release. Uploads post-and-page-builder.zip to the GitHub release for the tag, using GITHUB_TOKEN.

Files stripped before the SVN commit (not shipped to WordPress.org): node_modules, .git, .github, tests, bin, tools, bower_components, .travis.yml, release.sh, gulpfile.js, webpack.config.js, karma.config.js, yarn.lock, package.json, composer.json, composer.lock, phpunit.xml, README.md, CHANGELOG.txt, CONTRIBUTING.md, and various dotfiles. (Note: this strip list lives in the @boldgrid/wordpress-tag-sync package, not in this repo.)

Step 4 — Verify the release

  • WordPress.org SVN tag exists: https://plugins.svn.wordpress.org/post-and-page-builder/tags/X.Y.Z/
  • Plugin page shows the new version: https://wordpress.org/plugins/post-and-page-builder/ (the public page can take a few minutes to update).
  • GitHub release created with post-and-page-builder.zip attached: https://github.com/BoldGrid/post-and-page-builder/releases/tag/X.Y.Z — edit/clean up the release notes here (the body is not auto-generated).

Step 5 — Finalize on BoldGrid Central

The plugin is also delivered to Connect-key users through the BoldGrid Central update channel, which is separate from WordPress.org. Finalizing that release is a manual step in an internal management portal owned by the BoldGrid/release team.

TODO: document the exact portal URL and steps, and who has access.

Security releases

For vulnerability fixes, keep the tag message, GitHub release notes, and readme.txt changelog vague — e.g. Security Update: Patched a stored XSS in …. Full technical detail (finding IDs, exploit specifics) goes in the ENG/Jira ticket, not in any public-facing text.

Recovering a failed deploy

If the Travis build errors during deploy (the build reaches Run deployment but release.sh fails), the tag exists on GitHub but nothing shipped — no SVN tag, no GitHub release. The most common cause is WordPress.org SVN auth failure:

Creating New Tag
svn: E215004: Authentication failed and interactive prompting is disabled
svn: E215004: No more credentials or we tried too many times.

release.sh aborts here before any svn commit and before it builds the zip, so the release is clean to retry once auth is fixed.

To recover:

  1. Fix the credentials (needs Travis-admin + the wp.org account owner): update the WP_USERNAME / WP_PASSWORD repository environment variables in the Travis CI settings for BoldGrid/post-and-page-builder. (wp.org account password resets are the usual reason these go stale.)
  2. Re-run the release — either:
    • Restart the build in the Travis UI (the failed tag build's page → Restart build). Cleanest — re-runs the same tag deploy. OR
    • Re-push the tag to trigger a fresh build (pushing an existing tag is a no-op, so delete and recreate it): 
      git push --delete origin X.Y.Z && git tag -d X.Y.Z
git tag -a X.Y.Z -m "Release X.Y.Z"
git push origin X.Y.Z
  3. Verify as in Step 4.

Manual SVN fallback (bypasses Travis entirely — appears to be how some recent releases shipped; see note below): with valid wp.org SVN credentials, check out the plugin SVN repo, copy trunk → tags/X.Y.Z, sync trunk with the new release files (incl. updated readme.txt), and svn commit.

Note: WordPress.org has shown versions that have no matching git tag (e.g. it sat at 1.27.10 while the latest git tag was 1.27.9). That implies some releases were committed to SVN manually, outside this tag→Travis flow — likely because Travis SVN auth has been broken for a while. Confirm with the release team which path is currently the source of truth.

Troubleshooting

Symptom Likely cause
Deploy step never ran Tag build wasn't on PHP 7.4, or the ref wasn't a tag (on: tags: true).
Build errors at Run deployment with svn: E215004 WP_USERNAME / WP_PASSWORD invalid or rotated — see Recovering a failed deploy.
No GitHub release / zip Deploy failed before release.sh built the zip, or GITHUB_TOKEN invalid/missing scopes.
WordPress.org still shows old version Deploy failed, or readme.txt → Stable tag: doesn't match the pushed tag, or the tags/X.Y.Z dir wasn't created.
Wrong files shipped Strip list is in @boldgrid/wordpress-tag-sync/release.sh, not this repo.

Clone this wiki locally