TL;DR: I'll be focusing on a large codebase rework that should make maintaining multiple Minecraft versions much easier. It will take time and I may neglect other features/bug fixes whilst I work on it.

I've been considering using a multi-version repository for a while now. It seems like stonecutter-kt would help with that. This should probably be my priority for now as it would make maintaining different versions much easier.

I'm considering creating classes that wrap Minecraft and Fabric methods that are often used throughout the codebase. The wrapper methods would utilize stonecutter to modify the code for each version, which would result in the wrapper method essentially becoming version agnostic.

For example, imagine seeing this throughout the codebase for every translatable text call:

/*? if >1.19 {*/
return Text.translatable(...)
/*?} else {*//*
return new TranslatableText(...)
*//*?}*/

It would get very cluttered very quickly. And if they changed to another syntax in 1.21 or something? Yikes. But if I write a wrapper method with that same code, the rest of the codebase can simply use the method and it would be much easier to read (and much easier to maintain, as I can use it without thinking about version-specific code).

This change would also allow me to clean up the repository.. I could remove all of the version branches and use branches that represent a specific feature, hotfix, etc.

Version Support Progress

Updated 5/27/2024

• 1.17.1
• 1.18
• 1.18.2
• 1.19
• 1.19.1
• 1.19.2
• 1.19.3
• 1.19.4
• 1.20
• 1.20.1
• 1.20.2
• 1.20.3
• 1.20.4
• 1.20.5
• 1.20.6
• 1.21

Finally got around to actually setting up stonecutter-kt. I'm using each version's gradle.properties to populate fabric.mod.json.

Now I need to go through each version, one-by-one, porting each to the multi-version codebase and decoupling version-specific code to the abstraction (wrapper) classes (where most of the stonecutter code will reside): FabricAbstractions, MinecraftAbstractions. This will move all the "mess" of the different versions' code to two main files and the rest of the codebase should be relatively clean and easy to work with.

Lastly, I'll need to figure out a GitHub Actions workflow for releasing multiple versions at once to CurseForge and Modrinth.

I'll be porting 1.20 and 1.20.1 next and then start porting to 1.20.5 and 1.20.6.. and then start working on that GitHub Actions workflow so I can publish multiple versions at once.

Alright, 1.20 and 1.20.1 are ported over. I need to test the currently ported versions more thoroughly and then I'll start porting 1.20.5 and 1.20.6.

Alright, I've done a few things since the last update:

1. The workflow file for publishing multiple versions has been created and tested.
2. I've merged feature/stonecutter into the main repository.
3. I've archived the supported branches (see tags) and the feature/stonecutter branch.

I'll be starting on porting to 1.20.5 and 1.20.6 soon. After that, I'll begin porting the 1.19 versions.