Compatibility

Sigil runs on Minecraft 1.18-26.x, on Spigot, Paper, Purpur, Pufferfish and Folia, from one jar.

Probes, not version strings

Sigil picks an implementation per server by probing for the capability, never by comparing version strings. Forks misreport versions, and a probe tests the thing that actually matters, which is whether the method is there.

What degrades, and what happens instead

Feature	From	Below that
Named item models	1.21.4	falls back to custom model data
Max stack size	1.20.5	not needed; unique stack data prevents stacking anyway
Smithing transform recipes	1.19.4	recipe skipped and reported at startup
Grindstone protection	Paper	absent, reported at startup

Anything unavailable is downgraded per feature without aborting the rest of the load and is reported once in a startup block, so nothing is quietly broken without being named.

Folia

Supported. All scheduling goes through an abstraction with a region-threaded backend; there is no BukkitRunnable or Bukkit.getScheduler() anywhere in the plugin.

If you are writing an ability, use ctx.scheduler() and the same code is correct on both, because off Folia the region-aware methods collapse onto the main thread. See the API.

Reporting a version problem

/sigil platform

Prints the detected server, the compatibility tier chosen and which scheduler is in use. Paste that plus the startup block containing any gate lines, and the interesting part of the answer is usually already in it.

Building from source

Sigil shades Keystone into its jar, and Keystone is published, so mvn install is all you need:

mvn install

keystone-parent is Sigil's Maven parent, and Maven resolves a parent before it reads the project's own <repositories>, so the Nexus repository has to come from your ~/.m2/settings.xml:

<profiles>
  <profile>
    <id>bwmp-nexus</id>
    <repositories>
      <repository>
        <id>bwmp-nexus</id>
        <url>https://nexus.bwmp.dev/repository/maven-public/</url>
      </repository>
    </repositories>
  </profile>
</profiles>
<activeProfiles><activeProfile>bwmp-nexus</activeProfile></activeProfiles>

Building Keystone from source and mvn install-ing it locally also works, and is the way to test an unreleased change:

git clone https://github.com/bwmp-dev/Keystone && cd Keystone && mvn install

The result is sigil-plugin/target/Sigil-<version>.jar. There is no second plugin for server owners to install, because the framework is inside the jar.

Use the jar from sigil-plugin/target/, not the API module. The API is a compile-time dependency for addon developers; the plugin jar contains the runtime implementation and its shaded libraries.