Repository navigation
Post 2026-08-25 release merge - #2642
Conversation
WordPress 7.1 is imminent, so update the readme header for each of the ten plugins published to the plugin directory ahead of the upcoming releases. The unreleased od-* plugins have no readme.txt and are unaffected, and the "Requires at least" floor is left at 6.9. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Bumping a plugin version previously required an open, dated release milestone titled "<slug> <version>". That is a lot of ceremony for a release that only carries changes which are already merged, so add two ways to bump without one: * --increment <major|minor|patch|prerelease> derives the target version from the plugin's current "Stable tag". * --set-version <version> sets an explicit version for a single plugin. In either mode the plugins are named as positional arguments, matching the calling convention of generate-pending-release-diffs.sh. The list is required rather than inferred because the appropriate increment level differs per plugin, so no single auto-detected set would be correct. Passing --all targets every plugin for the rare case where one level does apply to all of them. The "prerelease" level increments the trailing number of the prerelease component, so 1.0.0-beta5 becomes 1.0.0-beta6. This is hand-rolled rather than delegated to semver, which yields 1.0.0-beta5.0 because it treats "beta5" as a single alphanumeric identifier. Incrementing a version that has a prerelease component by major, minor, or patch is refused, since that would silently graduate a beta to a stable release. All target versions are resolved before any file is written, so that guard aborts the whole run rather than leaving some plugins bumped and others not. The milestone-based behaviour is unchanged when neither new option is passed. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
…n-rules, web-worker-offloading Run via: ```bash npm run bump-versions -- --increment minor auto-sizes dominant-color-images speculation-rules web-worker-offloading ```
Run via: ```bash npm run bump-versions -- --increment prerelease embed-optimizer image-prioritizer ```
Fill in the empty changelog entries that bump-versions stubbed out for the seven plugins being released. The entries are written by hand because the changelog and prepare-release-notes commands derive their content from a release milestone, and these releases deliberately skip milestones. The bulk of each entry is the same across all seven plugins, since what is pending is a single cross-cutting sweep: strict types, native property types, and the raised WordPress 6.9 and PHP 7.4 minimums. Only three plugins carry anything beyond that: * Optimization Detective moved the URL Metrics storage HMAC validation into the REST endpoint callback and dropped its deprecated constants. * Speculative Loading hardened the JSON encoding of its inline scripts. * Image Prioritizer fixed TypeScript 6 type errors in the video lazy-loading script. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
The script could report a plugin as having no pending changes when it actually had some. Bumping "Tested up to: 7.0" to "7.1" replaces a line with one of exactly the same length, and the working copy is reused between runs, so a previous run's rsync leaves the build file's mtime on the copy. Both rsync's default quick check and SVN's own stat cache compare size and mtime rather than content, so each concludes the file is unchanged and "svn status" comes back clean. The failure is intermittent, since it only bites once a prior run has left a matching mtime behind, and it is silent in the worst way: the affected plugin is reported under a "No changes." note, which reads as confirmation that there is nothing to release. Pass -c so rsync compares checksums, and --no-times so the files it copies get a fresh mtime that invalidates SVN's stat cache. Both are needed; -c alone still leaves SVN unable to see the change. Verified against a cold checkout and a warm one, with identical results. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
The two web-vitals bundles under build/ accounted for 35% of the whole diff, 42 KB out of 124 KB, for what amounts to a library upgrade. They are minified despite not carrying a .min.js suffix, so the existing *.min.js exclusion misses them, and each is a single line, meaning any change at all renders as a whole-file rewrite. Exclude build/*.js, which brings the diff down from 127 KB to 85 KB. The sibling build/*.asset.php is deliberately left in, since its 'version' is the compact signal that the bundled library changed: two lines showing 5.1.0 becoming 6.1.0, in place of 42 KB of unreadable bundle. That signal turned out to be worth keeping. It surfaced that web-vitals is going from 5.1.0 to 6.1.0, across a major release, which was missing from Optimization Detective's changelog entry and is now added. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Excluding generated assets from the rsync kept the diff readable but blinded "svn status" to them, which is the wrong trade: status is the view that answers which files are being added, removed, and modified, and it should be complete. Worse, the exclusion also protected those files from --delete, so a stray minified asset dropped into an already-tracked directory was reported nowhere at all. Only one landing in a brand new directory showed up, and then merely as its parent directory, with no indication of what was inside. Copy everything instead, and filter "svn diff" so that generated files keep their header but have their contents replaced with a placeholder. They stay visible as changed without dragging in tens of KB of unreadable bundle: the whole report goes from 127 KB to 88 KB. The *.asset.php files are left intact, since their 'version' is the readable signal that a bundled library changed. Also expand unversioned directories in the status output, so that a batch of added files is listed file by file rather than collapsing into its parent. This supersedes the build/*.js exclusion added in the previous commit, whose carve-out for *.asset.php is preserved here by the same reasoning. Both edge cases are now covered: a stray min file in a tracked directory shows as "? stray.min.js", and a new directory lists its contents. It immediately turned up a real pending change that the exclusion had been hiding, a modified view-transitions .min.css, which on inspection is only a minifier emitting #0000 where it used to emit transparent. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
web-vitals began publishing source maps in 6.0.0, and emits a sourceMappingURL comment alongside them. That reference is correct inside the package, where the map sits next to the bundle, but the webpack config copies only the bundles out of node_modules. The upgrade would therefore have shipped two files pointing at maps that do not exist, making browsers request a URL that 404s whenever devtools is open. Copy the maps too, rather than stripping the comment. Upstream publishes them deliberately for exactly this case, and Optimization Detective is a plugin whose entire purpose is measuring real user performance, so readable web-vitals frames are worth having when debugging it or an extension built on it. Both maps carry sourcesContent, so they are self-contained and need nothing else fetched. The Gutenberg plugin ships source maps for the same reason; WordPress core does not, but core is not distributed as a plugin. The cost is 49 KB on a 106 KB zip, and nothing at runtime: browsers only request a map once devtools is open, so no visitor ever pays for it. Two renames had to be handled, since web-vitals.attribution.js is copied in as web-vitals-attribution.js. Its map is now named to match, the sourceMappingURL comment in the bundle is repointed at the new name, and the map's own "file" field is repointed at the renamed bundle. Both transformers are written as factories over a file name rather than hardcoded, since any vendored bundle renamed on the way in needs the same treatment. Note that the two added .map files are visible in the pending release diff as untracked additions only because generated assets are now copied and suppressed rather than excluded. Under the previous exclusion they would have been added to the plugin without appearing anywhere in the report. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
The release notes were the last step still requiring milestones, and it failed quietly rather than loudly. Only one of the seven plugins being released has a dated milestone, so prepare-release-notes produced notes for that one alone, and create-draft-release checked only that the notes file was non-empty. A draft release would therefore have been created covering one plugin out of seven, with nothing to indicate the other six were missing. The milestone was never the source of the content: getReadmeChangelogEntry() already reads each plugin's changelog from its readme.txt, and the milestone only decided which plugins to include. So accept plugin slugs as positional arguments and skip the lookup entirely when any are given, matching what bump-versions already does. There is deliberately no option to select every plugin here, unlike bump-versions where one exists but is rarely useful. A plugin that is not being released still has a changelog entry for its current stable tag, so including it would repeat an already-published entry in the new release notes. When plugins are named explicitly, a failure on any of them is now fatal and nothing at all is written, rather than the previous per-plugin tolerance emitting a subset. Asking for specific plugins and silently getting fewer is the exact failure this commit exists to prevent. Milestone selection keeps the old behaviour, since there the set was never asserted by hand. create-draft-release forwards any slugs through, then verifies each one is present in the generated notes before creating the draft. Where no slugs are given it now lists which plugins the notes actually cover, so an omission is visible rather than implied by silence. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Prepare 2026-08-18 release
|
The following accounts have interacted with this PR and/or linked issues. I will continue to update these lists as activity occurs. You can also manually ask me to refresh this list by adding the If you're merging code through a pull request on GitHub, copy and paste the following into the bottom of the merge commit message. To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook. |
Codecov Report❌ Patch coverage is Additional details and impacted files@@ Coverage Diff @@
## trunk #2642 +/- ##
=======================================
Coverage 70.35% 70.35%
=======================================
Files 91 91
Lines 7867 7867
=======================================
Hits 5535 5535
Misses 2332 2332
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Harness. 🚀 New features to boost your workflow:
|
Summary
Merges
release/2026-08-25back intotrunkfollowing the 2026-08-25 releases, per the release handbook. Everything here was already reviewed and approved in #2639, so this is the formal merge rather than a fresh review.trunkhas not moved since the release branch was cut, so nothing needed cherry-picking in the other direction and there are no conflicts.Three groups of changes land:
Released versions and changelogs for the seven plugins published in this release:
Tested up to: 7.1for all ten plugins. This matters fortrunkspecifically: Performance Lab, View Transitions, and Modern Image Formats were not version-bumped, and their readmes reached the directory through thebump-wordpress-tested-up-toworkflow rather than through a release. Until this merges,trunkstill reads7.0for every plugin, so the workflow would have nothing newer to publish if dispatched fromtrunkagain.Release tooling, which is the part worth being aware of for the next release:
bump-versionsaccepts--increment <major|minor|patch|prerelease>and--set-version <version>with plugin slugs as positional arguments, for releases that do not use milestones.prepare-release-noteslikewise accepts plugin slugs and reads each changelog fromreadme.txtinstead of requiring a dated milestone.create-draft-releaseforwards slugs through and verifies each appears in the generated notes.generate-pending-release-diffs.shhad two fixes: it could report a plugin as having no pending changes when it had some, and it excluded generated assets from the copy in a way that blindedsvn statusto them. Generated files now keep their entry in the diff with their contents replaced by a placeholder.Relevant technical choices
None beyond those already discussed in #2639.
The release itself is published: all seven plugins are on WordPress.org at their new versions, and all ten now report
Tested up to: 7.1. Distribution to sites is subject to WordPress.org's current six-hour review hold, so an update will not be offered through the update-check API until that window elapses. Direct ZIP downloads already serve the new versions.Use of AI Tools
Claude Code (Opus) prepared the release in #2639 and opened this merge PR. The full disclosure is on that PR; nothing new was authored here beyond this description.