How releases work
A stable release of one of our plugins is not published because someone decided it looked ready. It is published because it passed a set of automated checks, the release gates, on real Minecraft servers. The jar you download is the exact file that passed. If any check fails, nothing is published, and the failure is recorded in public on the plugin's issue tracker.
Every plugin page on this site shows the checks its current release passed, under Verified before release, with a link to each run.
Two channels
Stable is what this site, SpigotMC, and /dpm get give you. Stable releases are made only through the gates.
Dev is a pre-release rebuilt from every change, for anyone who wants to test what is coming (/dpm get --experimental). It has not been through the release gates.
The gates
API-compatibility check
Every build of every plugin, including every proposed change.
Every Bukkit class, field and method the plugin uses must exist on each Minecraft version the plugin supports, and the plugin must be compiled for a Java those versions run on. This is what would have caught a plugin that worked on the newest Minecraft but failed to start on an older one.
Boot gate
Every release, once per supported Minecraft version.
The exact jar that will be published is put on a fresh server of that version. It must enable cleanly, answer help for every command it declares, stop cleanly, and start a second time on the data it wrote.
Save-compatibility gate
Every release of a plugin that keeps data, once per storage backend it supports.
The current release writes data first, sometimes an anonymised copy of a real community server, with bot players adding more. The new release then loads that data through several restarts, and every count (players, factions, claims and so on) must match. Where a plugin can move data between storage types, the move is tested both ways.
Dependents gate
Every release of a plugin that other plugins build on, such as Medieval Factions.
The current release of every plugin that depends on it must still start against the new one. A plugin that was already broken is reported, not blamed on the release being checked.
Supported Minecraft versions
Each plugin lists the Minecraft versions it supports in a minecraft-versions.json file in its repository, and the gates check every version on that list. Most plugins currently support 1.19.4, 1.21.11 and 26.2.
When something goes wrong
A failed check blocks the release. A check on saved data is never waived: losing a server's data is the one thing a release must not do.
A bad release can be pulled. If a problem is found after publication, the release is withdrawn from the stable channel, and the previous one becomes what everyone gets again.
See for yourself
The gates are open source, and every run is public: release gates on GitHub. The rules for releases are written down in Release channels. Releases made before the gates existed carry no such record; their plugin pages show no verification.