versions.json entry
A community plugin release with no matching entry in versions.json
is one of the easiest release-blocking mistakes to introduce, because
manifest.json and versions.json live in two separate files, in two
different formats, with nothing forcing them to move together.
Obsidian's release mechanism reads versions.json to decide which installed app
versions can see a given plugin release. manifest.json carries only the
current release's version and its minAppVersion -- it says nothing about
history. Bump the version in manifest.json, tag the release, and forget to add the
matching line to versions.json, and the release exists but the version-resolution
step it depends on does not know about it.
| File | Example | What it controls |
|---|---|---|
manifest.json | "version": "1.4.0" | The current release's version string |
versions.json | { "1.4.0": "0.15.0" } | Which Obsidian app versions the release is compatible with |
Every version you have ever released should keep its own entry in versions.json --
it only grows, it never has old versions removed, since a user on an older Obsidian build may
still need to know which of your past releases it can run.
The checker on this site reads both files and tells you immediately if the current version has no matching entry, along with the other checks it runs (required manifest fields, leftover sample-plugin placeholder values, and the innerHTML/outerHTML/ insertAdjacentHTML pattern Obsidian's own developer guidelines flag). It runs as a browser tool (nothing uploaded) or a Node CLI you can add to your own pre-release check.
This is evidence of what the two files currently say, not a determination that a community-plugin submission will be approved in every respect -- see the checker and its disclaimer for what else it can and can't see, and verify against Obsidian's current plugin guidelines before you submit or tag a release.