Guides · Engineering

Which Minecraft versions should your plugin still support?

When to drop 1.8, 1.12 or Java 17 from your Minecraft plugin: how to read version data, what dropping costs, and how to do it without stranding servers.

Updated 9 November 2026 · by Skilled · 5 min read

Every Minecraft plugin with a few years behind it carries old versions around. A reflection helper for 1.8 materials, a branch for servers before 1.13, a build that still targets Java 8 because someone on 1.12 might complain. Each one makes the next feature slower to write and the next bug harder to find.

Dropping a version is easy. Knowing whether anyone still runs it is the hard part, and a guess in either direction costs you: drop too early and you lose servers that were happy, drop too late and you keep paying for a version nobody uses.

What supporting a version actually costs

Before looking at numbers, be honest about what each old version costs you:

• Code paths. Legacy materials before 1.13, the old chat and scoreboard APIs, NMS and reflection that breaks on every release.
• Java level. Supporting 1.8 to 1.16 servers on old Java means compiling for an older Java release and giving up records, switch expressions, text blocks and newer standard library methods.
• Testing. Every version you claim is a version someone will report a bug on. If you don't test it before each release, you're supporting it in name only.
• Dependencies. Libraries you shade drop old Java versions on their own schedule, and you either stay on their old releases or follow them.

If a version costs you nothing, there's no reason to drop it. If it costs you a day per release, it needs real users to justify it.

Your listing doesn't know

The versions you tick on SpigotMC, Modrinth or Hangar are what you claim, not what servers run. Download counts don't say either: a download for 1.8 might be someone testing, and a server that downloaded your plugin two years ago and still runs it never shows up again.

What you want is the version of every server that is running your plugin right now. Asking in Discord gets you the loudest few. bStats shows versions on a public page, for the servers that haven't turned it off.

With PluginAnalytics, every server that runs your plugin reports its Minecraft version, Java version, server software and your plugin's version, with no code beyond starting the SDK. The Servers page breaks active servers down by each of them and charts them over time, on every plan. What's collected

Reading the numbers

Look at three breakdowns together, not one:

Minecraft versions. The obvious one. Group them the way your code does: if you have a branch for "before 1.13", sum everything below 1.13 into one number.

Java versions. Often the real constraint. A server on 1.20.4 can still run Java 17, and if you compile for Java 21, your plugin fails to load there with an UnsupportedClassVersionError. Minecraft 1.20.5 and later need Java 21, so servers on those versions already have it; older ones may not.

Your plugin's versions. Servers on old Minecraft versions are often on old versions of your plugin too, and plan to stay there. If almost every 1.12 server runs a release from two years ago, dropping 1.12 in your next release changes nothing for them: they weren't going to update anyway.

Watch the trend more than the snapshot. A version at 6% that was at 15% a year ago is on its way out on its own. One that has sat at 6% for two years is a stable group with a reason to be there, usually a PvP or modded community, and dropping it means losing them.

A rule of thumb

There's no correct threshold, but a workable one:

• Under 2% of active servers, and falling: drop it in the next major release.
• 2% to 10%: keep it, but stop adding features there. Fix crashes only.
• Over 10%: it's a real part of your audience. Keep supporting it, or decide openly that you're leaving it behind and say so.

Weigh it against cost. A version at 4% that needs its own NMS module is a different decision from one at 4% that costs a single if.

How to drop a version without stranding servers

Keep the last release that supports it available. On SpigotMC and Modrinth, older versions stay downloadable. Say in your update post which release is the last one for the dropped version, so owners know where to stay.

Make the failure clear. A plugin that refuses to load with a clear message is far better than one that loads and throws on the first event. Check the version in onEnable and disable yourself with a message that says what to do:

@Override
public void onEnable() {
    if (!isSupported()) {
        getLogger().severe("ArenaPlus 2.0 needs Minecraft 1.17 or newer. Use ArenaPlus 1.9.x on this server.");
        getServer().getPluginManager().disablePlugin(this);
        return;
    }
    analytics = PluginAnalytics.start(this, "pa_your_key");
    // ...
}

api-version in plugin.yml helps too: Spigot and Paper refuse to load a plugin whose api-version is newer than the server, so setting it to the oldest version you support keeps older servers from loading it at all. Servers before 1.13 don't know the field, so keep the check in onEnable as well.

Warn before the release, not after. If you have a way to reach the servers that will be dropped, use it a release ahead. With update notices, you set the message from the dashboard and servers on older versions of your plugin see it in the console, and optionally admins in chat when they join.

Check after the release

After shipping the release that drops a version, two things tell you whether it went well. On the Servers page, the Upgrades and rollbacks table counts, for each of your versions, the servers that updated to it and the ones that went back to an older version afterwards. Servers on a dropped Minecraft version that updated anyway tend to show up as rollbacks: that's expected, but if the number is much larger than the share you dropped, something else in the release is wrong. And errors from your new version on old servers mean your version check isn't catching everything. Did your update break something?

Going the other way: new versions

The same data answers the opposite question. When a new Minecraft release comes out, the share of your servers that move to it tells you how fast you need to follow, and whether that new API you want to use can be required yet or still needs a fallback. Most servers wait for their other plugins before updating, so the first weeks are usually a small share, growing steadily.

Supporting fewer versions well beats supporting many badly. Decide with the servers you actually have, not the ones you remember. How many servers use your plugin

More guides