Blender 5.2 LTS and 5.3 alpha reject VRM add-on extensions over exclusive version cap

Users who moved to Blender 5.x are finding that the VRM Addon for Blender either never appears in the Extensions panel or silently refuses to switch on. A systematic write-up on dev.to, published 22 September 2026, traces the break to a single manifest field: blender_version_max is an exclusive bound, naming the first Blender version an extension does not support rather than the last one it does.

An exclusive cap, not an inclusive one

Since Blender 4.2, add-ons ship as extensions whose zip carries a blender_manifest.toml declaring blender_version_min and blender_version_max. Mismatched values do not stop the files from unpacking; they stop activation. On Blender 5.2.2 LTS with add-on 4.3.0, the console logs an error stating the Blender version must be less than the maximum version (5.2.0), while the Extensions panel shows nothing at all — the VRM entry simply is not listed.

The Blender manual's manifest example makes the semantics explicit: the max field names a version the extension does not support, with earlier versions supported. So VRM add-on 4.3.0, declaring 5.2.0, covers 4.2 through 5.1.x and is blocked from 5.2.0 onward regardless of patch number. The current 4.7.1 declares 5.3.0, which reaches 5.2 LTS but stops short of the 5.3 alpha.

Thirty-two combinations, two install paths

The author, testing headless on Apple Silicon macOS, installed add-on versions 3.9.0, 4.3.0, 4.4.0 and 4.7.1 into Blender 5.0.1, 5.1.2, 5.2.2 LTS and a 5.3.0 alpha, twice each — once as an extension zip, once as the legacy add-on zip — with a fresh user-resources directory per cell, 32 combinations in all.

On the extension path the gate behaved exactly as the manifests imply: 4.3.0 enabled on 5.0.1 and 5.1.2 but not on 5.2.2 or the alpha; 4.4.0 and 4.7.1 enabled through 5.2 LTS and failed only on the alpha. The legacy zip has no version gate at all. Every 4.x release enabled on all four Blender builds, including the 5.3 alpha, and passed an import-export-import roundtrip against both a VRM 0.x sample and a VRM 1.0 sample. All 20 cells that enabled passed; that roundtrip was the extent of functional checking, and exporting the VRM 1.0 sample grew it to roughly 152 percent of its original size, a change the author did not investigate.

Pulling the manifest from all 71 release tags shows blender_version_min fixed at 4.2.0 throughout; only the max has moved, four times:

blender_version_max	Add-on releases	Enables on
5.0.0	3.9.0 – 3.15.0	Blender 4.2 – 4.5
5.1.0	3.16.0 – 3.21.1	Blender 4.2 – 5.0
5.2.0	3.22.0 – 4.3.3	Blender 4.2 – 5.1
5.3.0	4.4.0 – 4.7.1	Blender 4.2 – 5.2 LTS

The practical rule follows directly: 5.2 LTS needs add-on 4.4.0 or newer, while 5.0 and 5.1 run the latest 4.7.1 without trouble.

The one hard failure

Version 3.9.0 fails on every path. Blender 5.0 removed bpy.types.ShaderNodeTexDensity, which that release imports at module load, so even the legacy install dies with an ImportError before activation. No route makes the 3.9.0 line work on 5.x.

Why the panel looks empty

The Extensions panel is not hiding an error. It queries the extensions.blender.org API with a server-side Blender-version filter; a request for 5.3.0 returns no vrm entry at all, so the panel renders an accurate empty result.

Workarounds and caveats

For users on 5.2 LTS, moving the add-on to 4.4.0 or newer is the clean fix. If VRM is absent from the panel, the extension zip can be taken from the GitHub releases and installed from disk, since the panel only ever offers the single latest version. Where the extension is refused outright, the legacy zip bypasses the gate and is currently the only way to run 4.7.1 on the 5.3 alpha — but that lands outside the range the maintainer declares support for, so stepping back inside it is the first thing to try when something misbehaves. Scripted installs should note that the legacy zip's top-level folder name differs between release lines; discovering the module via addon_utils.modules() avoids hardcoding it.

Why it matters

The blocker is configuration, not code: add-on versions the extension gate rejects largely install and roundtrip fine once the gate is out of the way. That makes blender_version_max the field to watch on every Blender release — read it as the first unsupported version, not the last supported one, and expect maintainers to bump it promptly. For the wider ecosystem it is also a caution about discoverability: when the repository filters server-side, an unsupported build makes an add-on vanish rather than surface an incompatibility, which looks to the user like the extension no longer exists.