How do you manage multiple versions of a mod? | The Fabric Project | Page 1

void spruce Mar 29, 2025, 1:10 AM

#

I want to verify what versions of minecraft my mod works on, and for the ones that the mod doesn't work, fix it if it's simple enough.

I would imagine that to keep track of the changes I would need to use a branch for each version/version groups I'm working on.

But if I want to downgrade the minecraft version, do I simply change minecraft version inside fabric.mod.json and that's it? Is there something I should be aware of, or things that I shouldn't do?

Just looking for general dos and donts, even better if it comes from experience (And why).

fallen bronze Mar 29, 2025, 1:12 AM

#

github branches

#

and u just adjust to errors

#

it depends on the version always

#

for updates that dont break ur code, changing the fabric.mod.json is fine

void spruce Mar 29, 2025, 1:14 AM

#

Is there somewhere in the docs which matches the fabricloader versions and java versions with the minecraft version?

fallen bronze Mar 29, 2025, 1:14 AM

#

fabric loader is version independent

void spruce Mar 29, 2025, 1:14 AM

#

Ooh, so I can stick with the most recent one?

fallen bronze Mar 29, 2025, 1:14 AM

#

java u shouldnt be going far back enough to worry about

void spruce Mar 29, 2025, 1:14 AM

#

Fair

fallen bronze Mar 29, 2025, 1:15 AM

#

fabric loader can stay latest

#

java has been 17 since like 1.18 i think

real maple Mar 29, 2025, 1:17 AM

#

fallen bronze github branches

I do not recommend branches if you want to maintain more than just 2-3 versions. In my experience it takes up a lot of time to merge and switch branches.

fallen bronze Mar 29, 2025, 1:17 AM

#

please dont say something gross like stonecutter

real maple Mar 29, 2025, 1:18 AM

#

fallen bronze please dont say something gross like stonecutter

Use stonecutter

fallen bronze Mar 29, 2025, 1:18 AM

#

and theres really no reason to support more than 3 versions

real maple Mar 29, 2025, 1:18 AM

#

That's your opinion

fallen bronze Mar 29, 2025, 1:18 AM

#

bleeding, latest major, and maybe an LTS

#

in this case, 1.21.5, 1.21.1, and 1.20.1 if u feel necessary

void spruce Mar 29, 2025, 1:19 AM

#

Oh yeah, that reminded me of something. What about the game sources? When I change the version, do I need to generate the sources again, or do they go back automatically when I change the version in the fabric config?

real maple Mar 29, 2025, 1:20 AM

#

Why wouldn't I support older versions if it's very easy with stonecutter? You say 'support latest', I say if you've already got code working for that version, and you're using stonecutter, it's very simple to keep it working. Most of the time I don't have to do anything

fallen bronze Mar 29, 2025, 1:20 AM

#

you refresh gradle and gensources again every time u switch branches

void spruce Mar 29, 2025, 1:20 AM

#

Oof.

fallen bronze Mar 29, 2025, 1:20 AM

#

you can have each version be in a separate folder

#

its called a workflow system i think

#

a github thing

#

so u dont switch branches and overwrite ur code, u simply open the other project folder and its already generated

#

i havent looked into it much

real maple Mar 29, 2025, 1:21 AM

#

Anyway, @void spruce . Stonecutter is a relatively popular solution. It allows you to keep all your code on one branch, in one place, and only change the parts that differ between versions. It uses comments to enable/disable parts automatically.

#

I really recommend you check it out at least, even if tommy is not a fan. https://stonecutter.kikugie.dev/.

fallen bronze Mar 29, 2025, 1:22 AM

#

i wouldnt recommend doing that, just code normally

#

it shouldnt be that difficult to switch branches that u need a hacky gradle plugin

real maple Mar 29, 2025, 1:23 AM

#

Merging is the bigger issue.

fallen bronze Mar 29, 2025, 1:23 AM

#

leads to some ugly code imo

real maple Mar 29, 2025, 1:24 AM

#

fallen bronze leads to some ugly code imo

Yes stonecutter code can be ugly, but you can also wrap it in a function and forget about it. Most changes between versions are quite low profile.

void spruce Mar 29, 2025, 1:24 AM

#

Being fair, if the version will be mostly backported only and not worked on too much, I don't think merging is an issue.

#

Though I'll take a look. If it seems simple enough to setup...

real maple Mar 29, 2025, 1:25 AM

#

There are also other solutions besides branches and stonecutter. But I don't know them

void spruce Mar 29, 2025, 1:26 AM

#

Oh god, this is cursed

fallen bronze Mar 29, 2025, 1:26 AM

#

harold

#

yeah

real maple Mar 29, 2025, 1:27 AM

#

real maple Merging is the bigger issue.

Oh and Gradle somehow very often ~always~ managed to get fd up when switching.

real maple Mar 29, 2025, 1:27 AM

#

void spruce Oh god, this is cursed

I don't disagree. But it works surprisingly well

fallen bronze Mar 29, 2025, 1:28 AM

#

yeah switching branches is a pita

#

which is why i suggested the workflow setup

#

that might not be the name

void spruce Mar 29, 2025, 1:28 AM

#

Yeah, stonecutter seems like a simple solution, but it really wouldn't do anything for the sources

fallen bronze Mar 29, 2025, 1:28 AM

#

but essentially a different folder for every branch

void spruce Mar 29, 2025, 1:28 AM

#

It feels weird to be making code for version A while code has the sources for version B

fallen bronze Mar 29, 2025, 1:29 AM

#

stops gradle and sources from breaking

real maple Mar 29, 2025, 1:35 AM

#

void spruce Yeah, stonecutter seems like a simple solution, but it really wouldn't do anythi...

Not sure what you mean by that.

#

Anyway i also just remembered that it's quite useful if you ever wanna support neoforge. Because you can also so //? if isNeoForge or isFabric

void spruce Mar 29, 2025, 1:38 AM

#

I mean is that, if I my sources are set to version 1.21.5, but I'm making code for like, 1.20 using stone cutter, and I want to browse the sources for this version I'm coding for, I would still need to generate the sources again it seems.

real maple Mar 29, 2025, 1:39 AM

#

Not really, often it works to use the correct sources automatically. Sometimes you just need to select them again, and yeah sometimes you need to decompile again.

dapper delta Mar 29, 2025, 1:40 AM

#

This certainly has some clear disadvantages (such as being a dependency injection nightmare) so I'm not sure I recommend it, but I've been using multiple submodules for this

#

e.g. I have a :common module with shared (non-Minecraft) classes/interfaces, and a :mc1.21.4 that implements those interfaces and initializes the mod for a specific version

fallen bronze Mar 29, 2025, 1:40 AM

#

real maple Anyway i also just remembered that it's quite useful if you ever wanna support n...

concern please dont do this, just use multiloader

real maple Mar 29, 2025, 1:41 AM

#

Use multiloader?

fallen bronze Mar 29, 2025, 1:41 AM

#

https://github.com/jaredlll08/MultiLoader-Template

#

subprojects

#

dont use stonecutter for multiloader mods

#

while i dont like it i can see some use for multiversion

#

but it definitely shouldnt be used for multiloader

real maple Mar 29, 2025, 1:43 AM

#

fallen bronze subprojects

Agreed, this way is arguably better. But it can be a bit more work sometimes.

cedar raptor Mar 29, 2025, 2:38 AM

#

stonecutter has a ready to use multiloader multiversion template btw

old frigate Mar 29, 2025, 7:29 AM

#

fallen bronze i wouldnt recommend doing that, just code normally

The main and huge minus of branches is their synchronization. Let's take a situation: You even have 3 branches for different versions of Minecraft, you found several bugs in different parts of the code, and in order to fix it qualitatively you will need to switch to **all **branches, and everywhere write the same fix for **each **bug that you need to remember, and its place in the code

#

With Stonecutter you have one code and you can control it for all versions of Minecraft at once, which greatly reduces the cases where you forgot to sync something somewhere

young warren Mar 29, 2025, 8:32 AM

#

old frigate The main and huge minus of branches is their synchronization. Let's take a situa...

that's overselling it a bit, branch switching time can be negated by using separate directories and once you've done the fix on the base branch you can chain rebases to apply it to the others, you'll only need to cherry pick if it's in version-modified code

old frigate Mar 29, 2025, 8:41 AM

#

I tried, and it was terrible. After all, I personally find it easier to perceive the code for all versions at once

young warren Mar 29, 2025, 8:56 AM

#

I've been doing it for a long time with up to 6 branches per mod and I don't find it too difficult but that's just me ¯_(ツ)_/¯

#

to be clear I'm not saying it's better than stonecutter, just that not everyone's experience will be as bad as yours

cedar raptor Mar 29, 2025, 11:24 AM

#

-# or you just don't make all in one jars as they often are often larger and may confuse users

void spruce Mar 30, 2025, 10:58 PM

#

I... Did not really understand what you are doing there. It seems like relatively advanced stuff, and I'm not really experienced with fabric or the Java environment.

#How do you manage multiple versions of a mod?