WP Packages Now Supports dev-trunk with SVN Revision Pinning

Ben Word 2026-03-26

Over 20,000 WordPress plugins on wordpress.org don’t tag their latest version in SVN. Some release exclusively via trunk, while others have older tags but not for the current version. Until now, these plugins were difficult to install reliably via Composer.

The problem

WordPress.org’s plugin repository uses SVN, and the recommended practice is to tag every release. A significant number of plugin authors only push to trunk, meaning the latest version isn’t available as a tagged release.

This affects roughly 33% of all active plugins. You can see the full list on our untagged plugins page.

Why isn’t Composer installing the latest version?

If you’ve noticed that composer update isn’t pulling the latest version of a plugin, the author likely pushed their release to SVN trunk without creating a tag. WordPress.org will serve this version to users who download directly, but Composer repositories can only serve tagged releases as stable versions.

We surface this directly on each plugin’s page. If the latest version isn’t tagged, you’ll see a warning at the top explaining the situation and offering a one-click copyable dev-trunk install command. For plugins that release exclusively via trunk, the main install command automatically uses dev-trunk.

You can also browse all affected plugins on our untagged plugins page.

How WPackagist handles it

WPackagist serves untagged versions by pointing to the trunk zip download with a ?timestamp= cache-busting parameter. This forces Composer to re-download when the timestamp changes, but the zip URL still points to whatever trunk currently contains.

This means composer install from a lock file doesn’t give you the same code that was locked. If the plugin author pushes to trunk between when you locked and when you deploy, you get the newer version that you haven’t tested. This can result in unexpected plugin updates in production.

WPackagist also serves these trunk installs as fake stable versions. Users have no indication they’re getting mutable, untagged code. With WP Packages, trunk installs are explicitly dev-trunk, so you’re always opting in knowingly.

Our approach: SVN revision pinning

WP Packages now serves dev-trunk for every plugin, pinned to a specific SVN revision. When you install a dev-trunk package, your composer.lock records something like:

{
  "source": {
    "type": "svn",
    "url": "https://plugins.svn.wordpress.org/optima-express/",
    "reference": "trunk@3478537"
  }
}

trunk@3478537 always checks out that exact revision. composer install on a fresh clone gets the same code every time. Your lock file is actually reproducible.

How to use it

Install any plugin from trunk:

composer require wp-plugin/example-plugin:dev-trunk

Composer will resolve the package from our ~dev.json metadata files, check out trunk at the current SVN revision, and lock it. Future composer install runs reproduce that exact revision.

This works for any active plugin, whether it’s trunk-only or just has an untagged latest version.

What’s happening under the hood

We extract per-plugin SVN revision numbers from the SVN changelog during our discovery pipeline (which runs every 5 minutes). Each plugin’s latest revision is stored and used when generating Composer metadata. The ~dev.json files follow the Composer v2 metadata-url convention for dev packages.

Tagged versions continue to be served from the main p2/<name>.json files with dist (zip) downloads as before. The ~dev.json files are additive — they don’t affect existing tagged version installs.

Recommendations

If you depend on a plugin that only releases via trunk, we’d still recommend asking the author to tag their releases in SVN. Tagged releases are the WordPress-recommended practice and provide proper semantic versioning.

But when that’s not an option, dev-trunk with SVN revision pinning is now a safe, reproducible alternative.

The WordPress Meta Team is also exploring upstream fixes, including an auto-tagging tool that would run svn copy /trunk /tag/XYZ for plugin authors automatically. If that ships, it would eliminate the untagged problem at the source. Follow the discussion GitHub.

See the comparison of WP Packages and WPackagist

For a full comparison of how WP Packages and WPackagist differ, see our WP Packages vs WPackagist page.