Year-Based Version Numbers and Unobfuscated Jars: What Changed in How Minecraft Java Ships in 2026
Why Minecraft Java went from 1.21.11 to year-based versions like 26.1, what unobfuscated jars change for Paper plugins and Fabric mods, and what to check before you move a server to 26.x.
ChunkPod Team · · 10 min read
Year-Based Version Numbers and Unobfuscated Jars: What Changed in How Minecraft Java Ships in 2026
Minecraft Java Edition 1.21.11, the Mounts of Mayhem drop released on December 9, 2025, was the last version to carry a 1.x number. It was also the last version Mojang shipped with obfuscated code. Everything after it uses a year-based version number and ships with readable class, method and field names.
Each change sounds small by itself. Together they change how you read a changelog, which jar you download and why some plugins broke on day one. This post covers what Mojang has announced and shipped, and what the Paper and Fabric teams have said about it.
The new version numbers
There's no 1.22. The 1.x line stopped at 1.21.11. Starting with the first drop of 2026, Java and Bedrock versions follow a year.drop.hotfix pattern:
- The first number is the year, so everything released in 2026 starts with 26.
- The second number is the drop within that year: 26.1 is the first drop, 26.2 the second, and so on.
- A third number, when there is one, marks a hotfix or patch on top of that drop, such as 26.1.1 or 26.1.2.
Mojang now ships several smaller game drops a year instead of one big yearly update, and the numbering follows that. In 2026 that has meant:
- 26.1 (Tiny Takeover), released March 24, 2026
- 26.2 (Chaos Cubed), released June 16, 2026
- 26.3 (Wilderness Bound), released September 15, 2026
Development builds follow the same pattern. Snapshots have names like 26.1-snapshot-1, so you can tell which drop a snapshot belongs to just from its name. Under the old system you had to learn that week-coded snapshots such as 24w14a were headed for a particular 1.21 release.
What this means when you read a changelog
The old numbers made every drop look like a minor bump. 1.21.4 and 1.21.5 looked like patches, but each one changed world generation, mob behavior or data formats. Plenty of admins updated because "it's just a .x release" and found half their plugins broken.
The new numbers are clearer. A change in the second number (26.1 to 26.2) is a full content drop. Expect new blocks, new mobs, a new protocol version and new data pack and resource pack formats. Treat it as a real update and check your plugins and mods first. A change in the third number (26.1.1 to 26.1.2) is a hotfix on the same drop. Those are usually much smaller, but read the notes anyway, because a hotfix can still change the protocol.
The year tells you how old a version is. If someone asks for help with a 26.1 server in 2027, you know right away that they're a year behind.
What this means when you pick a server jar
Server software has moved to the new scheme too. Paper's 26.1 announcement says it has adopted Mojang's versioning, and it changed its own build identifiers along with it. The old 1.21.x-R0.1-SNAPSHOT style is gone. Builds now look like 26.1.2.build.23-alpha: the Minecraft version, the build number, then a status such as alpha. Download pages, plugin pages and dependency files all use version strings in this format now.
One detail that catches people out: 26.1 is the first version that requires Java 25. 1.21.11 was the last one that ran on Java 21. If your host or your start script still points at Java 21, a 26.x jar won't start. Check which Java your panel or script actually uses before you swap jars, not after.
What this means for plugin compatibility
Plugin pages list supported versions, and for a while you'll see both styles side by side: "1.21.4 - 1.21.11" on one page, "26.1+" on the next. Keep in mind:
- A plugin that lists 1.21.11 as its newest version hasn't said anything about 26.x. Don't assume it works.
- "26.1" on a plugin page doesn't automatically cover 26.2. Each drop is a content update, and plugins that touch game internals can break between drops, the same way they broke between 1.21.x releases.
- Version range checks written for
1.xnumbers can get confused by a number like26.1. That's a problem for plugin authors to fix, but it helps to know about it if a plugin refuses to load with a strange version error.
Unobfuscated jars
This is the bigger change for anyone who writes plugins or mods, and it also affects admins who run them.
What obfuscation was
Since the start, Mojang has put Minecraft Java through an obfuscator before shipping it. That tool replaces readable names in the compiled code with short meaningless ones. A class that Mojang's developers called something like ServerLevel would ship as brc or some other scrambled string, and every version got different scrambled names.
Modding worked around this for years. Community projects built their own name mappings, such as MCP for Forge and Yarn for Fabric. Fabric also used an in-between layer called Intermediary, which gave names that stayed stable across versions. In 2019 Mojang started publishing official mappings files so developers could translate the scrambled names back to Mojang's own. Even so, the game itself still shipped scrambled, so every toolchain needed a remapping step somewhere.
What Mojang changed
In late 2025 Mojang announced it would stop obfuscating Java Edition, starting with the first snapshot after Mounts of Mayhem. To give toolchains time to prepare, it shipped experimental unobfuscated versions alongside the normal ones during the 1.21.11 snapshot cycle, including a separate "1.21.11 Unobfuscated" build.
26.1 is the first Java Edition release that is fully unobfuscated, with no obfuscated version shipped alongside it. The client and the server jar now contain Mojang's real class, method and field names. Bedrock Edition isn't affected.
What it changes for Paper and plugin developers
Paper has run on Mojang's names internally for a while. Since 1.20.5, Paper has shipped a Mojang-mapped server by default. Plugins that reached into server internals (the code people call NMS) were usually built against Spigot's mappings, so Paper remapped those plugins to Mojang names the first time they loaded.
With 26.1 that layer is gone. Paper says that because Mojang no longer ships obfuscated server jars, it has fully dropped its internal remapper. Paper's developer docs also say reobfuscated plugins won't work from Paper 26.1 onwards, and that Paper no longer supports remapping plugins to Spigot runtime mappings.
Here's how that plays out:
- Plugins that only use the Bukkit or Paper API never touched obfuscated names, so this change doesn't affect them. They still need to handle whatever gameplay and API changes each drop brings.
- Plugins that use server internals and were built with Spigot's reobfuscated mappings won't load on Paper 26.1 or newer. Their authors need to publish a build that targets Mojang's names. Paper's paperweight-userdev tool already builds plugins that way.
- Plugins built against Mojang mappings for Paper skip the first-load remapping they used to go through.
If you moved a server from 1.21.11 to 26.x and a plugin that worked fine before suddenly throws class or method errors, check this first. It's often a plugin that used internals through Spigot mappings and hasn't been rebuilt yet.
What it changes for Fabric and other mod loaders
The Fabric team wrote about its plans right after Mojang's announcement. For Fabric, the changes are:
- Intermediary goes away for new versions. There are no scrambled names left to translate, so the in-between layer isn't needed.
- Yarn is being discontinued in its current form. The Fabric team said it couldn't justify maintaining Yarn once the game ships with official names. Mods for new versions use Mojang's names.
- Fabric API moves to official names, and Fabric's build tool Loom has tooling to help mod authors migrate and rename their code. Fabric also said it wants to keep supporting older, obfuscated Minecraft versions.
For mod authors, the switch to Mojang names is a one-time migration. After that, one set of names covers everything: Mojang's own code, the Fabric toolchain and anyone else reading the game's code. Mojang's official names also include parameter and local variable names, which the older mappings didn't have. That makes decompiled game code much easier to read when you're working out what changed.
As a server admin, you'll mostly see the effects indirectly. Mods and plugins built for 1.21.11 and earlier were built against a different naming setup, so expect every mod on a modded server to need a fresh 26.x build. You'd expect that across a content drop anyway, but this time the toolchain changed too.
Will plugins and mods update faster now
Part of the old wait after each release was pure plumbing. A new version dropped with freshly scrambled names, and before anyone could port a mod, the mappings had to be updated, the tools had to handle the new version, and remapping had to work. With unobfuscated jars, that step is gone. The names in the jar are the names developers use, and they don't get scrambled differently in every version.
The mapping step was never the whole wait, though. Most of the time goes into updating code for what actually changed in the game: new blocks and entities, reworked systems, changed networking, changed data formats. Unobfuscation doesn't remove any of that. A mod that hooks deep into world generation still has to be rewritten when world generation changes. A plugin that sends custom packets still has to follow protocol changes.
There's also a short-term cost. The first unobfuscated releases came with a toolchain migration, so authors had to move to new names, new build setups and, on Paper, a Paper without a remapper. For some projects the first 26.x update took more work than a normal update, not less.
Mojang hasn't promised that mods and plugins will update faster, and nobody can promise it for thousands of independent projects. What you can say is that one real obstacle is gone for good, and each drop is smaller than the old yearly updates. Whether that shortens the wait for the plugins your server depends on comes down to how much each drop changes and how active each project's authors are.
What to check before you move a server to 26.x
- Java version. 26.x needs Java 25. Make sure your host or start script uses it.
- Server software build. Paper builds now use the
26.x.y.build.N-statusformat. Check whether the build you're downloading is marked alpha or stable before you put it on a live server. - Plugins that use internals. Anything built with Spigot's reobfuscated mappings won't load on Paper 26.1 or newer. Look for a 26.x build or an update note from the author.
- Mods. On Fabric and other loaders, every mod needs a build made for the exact drop you're moving to.
- Backups. Every content drop can change world data, so take a full backup before the first start on a new drop.
ChunkPod is a Minecraft hosting service in early access. If you'd rather not manage server updates yourself, you can join the waitlist at chunkpod.com to hear when hosting opens.