Improve correctness & simplify storage pipeline by dropping Composer v1 support

[tangrufus]

Proposal:

• Drop Composer v1 support (Drop Composer v1 support #34)
• Split feature branches into its own JSON, i.e: /p2/wp-plugin/akismet~dev.json (Split dev-trunk into ~dev.json for proper SVN revision locking #65)
• Correct trunk handling

- packages.json                           ← atomic pointer (build-id + URLs)
+ packages.json                           ← static
- p/wp-plugin/akismet$abc123.json         ← shared, uploaded once ever (immutable)
- p/providers-week$def456.json            ← shared, uploaded once ever (immutable)
  p2/wp-plugin/akismet.json               ← shared, overwritten when changed
+ p2/wp-plugin/akismet~dev.json           ← shared, overwritten when changed
- releases/20260314-150405/packages.json  ← per-release snapshot (immutable)
- releases/20260314-150405/manifest.json  ← per-release (immutable)

The new static packages.json:

{
    "available-package-patterns": [
        "wp-plugin/*",
        "wp-theme/*"
    ],
    "metadata-url": "/p2/%package%.json",
    "notify-batch": "https://wp-composer.com/downloads"
}

Composer v1

packagist.org has dropped Composer v1 support since September 2025.
If anyone is still using v1, they must be paying for private packagist or self-hosting a mirror.

The hashed providers urls are for Composer v1 only.
Without those hashed providers urls, /p2/wp-plugin/akismet.json is the only storage we need to update (except the DB, details later).

Tagged Versions & Feature Branches

Composer v2 looks for tagged versions (including unstable ones, e.g: patch, beta, etc) in /p2/wp-plugin/akismet.json and looks for feature branches in /p2/wp-plugin/akismet~dev.json.

Mapping this to wp.org SVN:

• https://plugins.svn.wordpress.org/akismet/tags/ --> /p2/wp-plugin/akismet.json
• https://plugins.svn.wordpress.org/akismet/branches/ --> /p2/wp-plugin/akismet~dev.json
• https://plugins.svn.wordpress.org/akismet/trunk/ --> /p2/wp-plugin/akismet~dev.json (merging trunk with branches)

Tagged JSON (/p2/wp-plugin/akismet.json) contains both dist and source whereas feature branches JSON /p2/wp-plugin/akismet~dev.json contains source only. trunk does not contains dist to avoid caching issues.

Problem with trunk

{ 
           "version": "8.1.21",
           "source": {
                "type": "svn",
                "url": "https://plugins.svn.wordpress.org/activecampaign-subscription-forms/",
                "reference": "trunk"
            },
            "dist": {
                "type": "zip",
                "url": "https://downloads.wordpress.org/plugin/activecampaign-subscription-forms.zip?timestamp=1763105557"
            }
}

Composer expects immutability. The above example is wrong:

• trunk is not forever v8.1.21
• The zip is not foreverv8.1.21

Thus, the whole JSON example is wrong.

By providing only source on trunk. Composer infers the SVN revision number and properly lock the version.

If plugin developers never tag the plugin, users should only use dev-trunk and let Composer lock its SVN revision number.

Souring

Instead of sourcing from https://api.wordpress.org/plugins/info/1.2/, we will need to change to crawl from https://plugins.svn.wordpress.org instead.

Database

With support for Composer v1 dropped, /p2/%package%.json could become the single source of truth.
This is sufficient for normal users.

However, we want to mimic other packagist endpoints, enrich meta info and have a frontend for marketing. We will need to save into the database.

Maybe a feature flag for normal users to skip the DB and use /p2/ as the single source of truth. But leave that for the future.

[retlehs]

👍 on this direction, thanks for flagging and reporting this

[swalkinshaw]

I've been thinking about a larger refactor + simplification and dropping v1 support makes that way easier so I'll work on that as the very first step 👍

[retlehs]

Should we also change this in generated composer.json files?

"require": {
-  "composer/installers": "~1.0|~2.0"
+  "composer/installers": "~2.0"
},

Somewhat related: also proposed dropping Composer v1 support in the core installer package: roots/wordpress-core-installer#10

[tangrufus]

No for dropping composer/installers v1 because installers v1 still works with Composer v2.

The installers v1 -> v2 breaking changes are:

• Removed some package types
• Bumped PHP requirement

Neither affect WordPress plugins & themes.

Keeping installers v1 makes people migrate to wp-packages easier while adding no burden to us.

[retlehs]

Composer infers the SVN revision number and properly lock the version

This doesn't actually happen: Composer's SVN downloader stores the branch name ("reference": "trunk") in composer.lock, not the actual SVN revision number. So composer install on a fresh clone checks out whatever trunk currently is, not the revision from when it was locked.

Just shipped ~dev.json with both dist (trunk zip) and source (SVN) — users can install via composer require wp-plugin/<name>:dev-trunk, but true immutability isn't possible for trunk.

[retlehs]

Closing since everything besides immutability has been implemented, which we are tracking in #15