Porting a Fabric mod to Minecraft 26.3

I ported Araz, my Fabric horror mod, from Minecraft 26.1.2 to 26.3 in a single afternoon in September 2026. The compiler produced 56 errors. All of them came from ten repeated API patterns, and not one of them forced a design change.

This post is the list I wanted when I started. What got renamed, what moved package, and which build tool versions the new Loom demands. The mod itself did not change: the 26.3 build of Araz 1.0.0-beta.2 plays exactly like the 26.1.2 build.

Everything below comes from that one real port. I checked each line against the compiled source rather than a changelog. Your mod touches a different slice of the API, so verify every row against your own build before you trust it.

What changed between Minecraft 26.1.2 and 26.3 for Fabric mods?

Most of the breakage falls into four areas: entity type constants, sign text, coloured blocks and loot tables. Several of these landed in 26.2, which I skipped entirely, so a jump straight from 26.1.2 to 26.3 collects two versions of churn at once.

Two rows deserve extra attention. Removing hurtMarked is silent on mobs, because the entity tracker sends velocity anyway, but a player will simply not move unless you send the packet yourself. The colour collection, on the other hand, is a small win once you are past the rename: picking a random carpet is now Blocks.CARPET.white() or Blocks.CARPET.lightGray() instead of a switch over block constants.

Which Gradle and Loom versions does Minecraft 26.3 need?

Fabric Loom 1.18-SNAPSHOT is the plugin version for Minecraft 26.3, and it requires Gradle 9.7 or newer. I lost more time here than on any API rename, because the failure message points at plugin variants rather than at the wrapper.

The 1.21.10 backport is a different build entirely. It uses the net.fabricmc.fabric-loom-remap plugin with loom.officialMojangMappings(), every mod dependency declared as modImplementation, and Gradle run on JDK 21. If you keep several branches alive, keep the build files separate rather than trying to make one script cover all of them.

How I ported the mod in an afternoon

1. Copy the project, then bump the build

   I copied the 26.1.2 folder to a new one and left the old folder untouched as a working fallback. Then I set minecraft_version, loader_version, loom_version and fabric_api_version in gradle.properties and pointed the Gradle wrapper at 9.7.1.

2. Compile once and read the whole error list

   Do not fix the first error. Run the build, let it fail, and read all 56 lines. Almost every error repeats, so the list tells you how many distinct patterns you are really dealing with before you touch anything.

3. Fix by category, not by file

   I handled one pattern at a time across the whole source tree: every EntityType. constant, then every blocksMotion() call, then sign text, then carpets. One find and replace per pattern is faster and far less error prone than walking the file list.

4. Check what the compiler cannot see

   A change the compiler accepts can still be wrong at runtime. I checked loot table building, the mixin targets and the GeckoLib asset paths by hand, because a broken resource path stays quiet until the game actually loads it.

5. Run the client, then diff the data

   I launched the dev client, walked to a rebuilt abandoned camp to confirm sign text still renders on all four lines, and compared the generated loot against the 26.1.2 build. That last step is the only thing that catches a wrong Holder in the loot number providers.

What did not change in 26.3

The list of things that survived is much longer than the list that broke, which is why this was an afternoon and not a weekend. If your mod leans on these, you are mostly fine.

• ValueInput and ValueOutput for reading and writing NBT
• Custom network payloads and StreamCodec
• SavedDataType with an Identifier, so persistent world data kept working untouched
• The entity render state architecture, GuiGraphicsExtractor and HudElementRegistry
• CreativeModeTabEvents for adding items to creative tabs
• Mixins targeting Java 25

How do you check a port did not quietly break something?

A clean compile proves nothing about resources or runtime behaviour. Three things in Araz can pass the compiler and still be broken in game, so I check them by hand on every port.

• Signs. SignText now wants two lists of four lines. A wrong list length shows up as blank lines on the record signs the creature plants near your bed, not as a compile error.
• Loot. The number providers moved package and take a Holder, so I compare what actually drops against the 26.1.2 build instead of trusting that it compiled.
• Client-only code. Item activation moved from the game renderer onto the player, and with split source sets a client mixin has to be declared as {"config": ..., "environment": "client"} in fabric.mod.json or a dev server crashes on startup.

Which Minecraft versions does Araz support?

As of September 2026, Araz 1.0.0-beta.2 ships for Minecraft 26.3, 26.1.2, 1.21.10 and 1.20.1. All four are Fabric only. There is no Forge or NeoForge build and none is planned. Fabric API and GeckoLib are required; Simple Voice Chat, Mod Menu and Cloth Config are optional. The mod page is at spicesfire.com/araz.

Keeping four branches alive is affordable because the gameplay code is identical across them. The 26.3 release notes for Araz list one user-facing fix, a spawn egg texture that was missing from the mod file, and the rest is internals. Builds are on Modrinth and CurseForge, and I answer porting questions on Discord.

What this port does not tell you

These notes come from one port of one mod in September 2026. Araz uses a custom entity, block entities, items, loot, mixins and a GeckoLib renderer, so it hits a wide slice of the API. It touches world generation nowhere: the abandoned camp and the portal ruin are built when a player approaches, not during chunk generation. If your mod generates terrain, biomes or features, nothing in this post covers you.