Skip to main content

Releasing Mods

The built in publisher is the mod-publish-plugin.

When you are using the built in chiseledPublishMods command, you only need to override the things that are unique to your mod.

info

Stonecutter 0.7 (Stonecraft 1.8+) fans out the native Gradle tasks to every node, so most pipelines can invoke the root publishMods task directly and skip the wrapper. We still register the chiseledPublishMods alias for older scripts, and you can read why the native tasks are preferred in Stonecutter 0.7 and the Future of chiseled* Tasks.

Here is an example of how to set up the publishMods block for a mod that is both Modrinth and Curseforge:

build.gradle.kts
publishMods {
    modrinth {
        if (mod.isFabric) {
            requires("fabric-api")
            optional("modmenu")
        }
        requires("cloth-config")
    }

    curseforge {
        clientRequired = false
        serverRequired = true
        if (mod.isFabric) {
            requires("fabric-api")
            optional("modmenu")
        }
        requires("cloth-config")
    }
}

The name of the files, setting the version, the loader and other metadata is handled by Stonecraft. You can override the default values by setting them in the publishMods block as you would with the mod-publish-plugin.

Declaring Additional Compatible Versions​

If a single build of your mod should appear as compatible with multiple Minecraft releases, add the extra versions to your gradle.properties (or any file that ends up in the project's extra properties) using the additional_versions key. Stonecraft will automatically merge these values with the active Stonecutter version when configuring every publishing target.

gradle.properties
additional_versions=1.21.3, 1.21.2

This only affects the compatibility list shown on Modrinth and Curseforge; the file name and displayed version still use the active Stonecutter version so consumers know which build they downloaded.

Environment Variables​

There are a few environment variables that you must set depending on your project.

Publishing on Modrinth​

Environment VariableDescription
MODRINTH_TOKENThe token used to authenticate with Modrinth.
MODRINTH_IDThe ID of the project on Modrinth.

Publishing on Curseforge​

Environment VariableDescription
CURSEFORGE_TOKENThe token used to authenticate with Curseforge.
CURSEFORGE_IDThe ID of the project on Curseforge.
CURSEFORGE_SLUGThe project slug on Curseforge.

Other Environment Variables​

Environment VariableDescription
DO_PUBLISHSet to true to publish the mod.
This translates to the mod-publish-plugin's dryRun setting's opposite
RELEASE_TYPEThe type of release.
This can be one of alpha, beta or stable
If a value is not recognized, it will default to stable

Release Types​

Release types are used to determine the type of release you are making. In terms of Minecraft mods, it's usually used to determine if the mod is alpha, beta or stable release.

The simplest way to set this up is to use the RELEASE_TYPE environment variable in your CI/CD pipeline.

GitHub Actions​

In GitHub Actions, you can set the RELEASE_TYPE environment variable in your workflow file. This looks at the branch name and sets the release type accordingly. the main branch is set to release, the beta branch is set to beta, the alpha branch is set to alpha and everything else is set to snapshot.

Ideally you wouldn't call publish on anything but the main, alpha and beta branches.

env:
  RELEASE_TYPE: ${{ endsWith(github.ref_name, 'main') && 'release' || (endsWith(github.ref_name, 'beta') && 'beta' || (endsWith(github.ref_name, 'alpha') && 'alpha') || 'snapshot') }}

Setting it manually​

You can of course set the release type in your build file manually.

build.gradle.kts
publishMods {
    type=ReleaseType.BETA
    modrinth {
        if (mod.isFabric) {
            requires("fabric-api")
            optional("modmenu")
        }
        requires("cloth-config")
    }

    curseforge {
        clientRequired = false
        serverRequired = true
        if (mod.isFabric) {
            requires("fabric-api")
            optional("modmenu")
        }
        requires("cloth-config")
    }
}

Semantic Release - version string parser​

Me (Meza), I'm a big fan of semantic release and I think it should be the default way to release software. It's not only a great way to automate the release process, but it also helps you keep track of the changes in your project and deal with versioning.

It does require a bit of setup, and to get used to the conventional commit messages, but it's worth it in the end.

info

To support this flow, Stonecraft automatically attempts to determine the release type based on the version string of the project.

  • If a version contains the word "alpha", it will be treated as an alpha release.
  • If a version contains the word "beta", it will be treated as a beta release.
  • If a version contains the word "next", it will be treated as a beta release. (This is useful when you use the @next terminology from the npm ecosystem)
tip

If you don't want this behavior, you can set the RELEASE_TYPE environment variable and that will override the version string parser.

The above however sets the release type for the entire project.

Setting the release type for a specific mod​

You can set the release type for a specific mod by using the is_snapshot property in the versions/dependencies/[miencraft_version].properties file. Setting this to true will set the release type to beta and setting it to false will make Stonecraft behave normally.

versions/dependencies/1.21.4.properties
is_snapshot=true

If you are curious about how this works, checkout the SoundsBeGone mod or the Inventory Sorter mod where I use this technique to release the mod.

If you're still curious, join discord and ask me about it. I love talking about this stuff. (link in the footer)