Quark ships Minecraft features on a scripted, signed release train

Small things, and one borrowed animation engine

Quark describes itself in one line as small things, improving Minecraft without changing the core gameplay, and the project is a Java Minecraft mod under the VazkiiMods organisation, with a website at quark.vazkii.net and the documentation at quarkmod.net.

The scope statement is a design constraint rather than a slogan. A mod that does not change the core gameplay has to earn its place with quality of life changes that a player can accept and a server operator can live with, which is a different discipline from a mod that adds content.

The README also names the one external library the project calls out, the Java Universal Tween Engine by Aurelien Ribon, licensed under the Apache 2.0 licence. Tweening is the animation of a value over time, and a quality of life mod is full of small animated transitions, so a dedicated tween engine is a reasonable dependency to take rather than to write.

The repository itself is a Gradle project with a src/ directory, a spotless/ directory for formatting, a scripts/ directory and several build related property files, which is the shape of a mod that has been maintained across many game versions.

The release process is written down as six steps

The most useful documentation in the repository is the release process section, and it is unusually concrete.

1. Pull master so you're up to date, make sure everything is committed
2. Run `git tag -a release-<mc_version>-<build_number>`. If you don't know or remember what those are, look at `build.properties`

The steps that follow are to write the changelog in the editor that pops up, increment the build_number in build.properties by one for the next version and commit that, then push master and the release tag.

5. Push master and the release tag: `git push origin master release-<mc_version>-<build_number>`

And the last step is the payoff: shortly after, the mod should be automatically uploaded to GitHub's release tab, Modrinth, and CurseForge.

That final sentence is the whole point of the process being written down. The release process is mostly automated, and the six steps are the human part of it: the tag is the trigger, and everything after the push is machinery. A maintainer who knows these steps does not need to know how the pipeline works, and a new maintainer does not need to ask.

The tag naming scheme also carries information. The recent tags are release-4.1-487+1.21.1, release-4.1-486+1.21.1 and release-4.1-485+1.21.1, so the tag holds the mod version, the build number and the Minecraft version it targets, and the build number is the incrementing counter kept in build.properties.

Signed artefacts and how to check them

Releases are signed with the Violet Moon signing key, and the README points at a page in the organisation's own security repository for information about how to verify the artefacts.

Signing is not a detail to skip here, because a Minecraft mod is a jar that runs with the permissions of the game client, it is distributed from several platforms rather than one, and the people downloading it are being asked to trust a build they did not compile. A signature that can be checked against a published key turns trust from a matter of faith into a matter of a command.

The fact that the project points to a dedicated security page rather than describing the procedure inline also tells you something about how seriously the maintainers treat it. There is a whole repository, VazkiiMods/.github, whose security directory holds the material, which is the right place for a key and its verification instructions, separate from the code.

The build side of this lives in the repository too, with a Jenkinsfile for the pipeline, a push_tag.py script and a zupdate.sh script, which are the pieces a maintainer would look at first if an upload ever failed.

Project Zeta is the plan to leave Forge behind

The README flags a planned rearchitecture under the name Project Zeta, described as a planned rearchitecture of Quark to make it less tightly-integrated with Forge, with a roadmap in the author's post on the Violet Moon forums.

The framing is careful. Zeta is planned, not shipped. The README says there is still lots to do and points contributors at a zeta-todo/README.md file in the repository, so the work list is in the tree rather than only in a forum thread.

The reason a Forge dependency is worth removing is structural. A mod built tightly against a particular mod loader inherits that loader's version, its mappings and its release cadence, and every game update becomes a question about the loader as well as the mod. A mod that is less tightly integrated can move at the game's pace instead of the loader's.

The recent tag names give a sense of the scale of that commitment. The Minecraft version sits in the tag, so the project tracks game versions, and a rearchitecture of that kind is a large undertaking for a project whose releases arrive as often as these do. For a player, the practical question is simply whether the build they install supports the game version they play, and the tag answers that.

A repository with more than one way to build

The tree tells you that this is a project with several moving parts rather than a single module.

The Gradle side is a complete setup: build.gradle, settings.gradle, gradle.properties, a gradle/ directory and the gradlew and gradlew.bat wrapper scripts, which means a contributor does not need a local Gradle installation. There are then three separate property files, build.properties with the build number, dependencies.properties and contributors.properties, which means the build configuration, the dependency set and the credits are kept apart from the code.

Other directories have obvious purposes. spotless/ holds the code formatting setup, so formatting is enforced by tooling rather than by review. scripts/ holds the helper scripts, and localjars/ and oddities/ are the kind of directories that hold the things that do not fit anywhere else. QuarkWeb is a separate project inside the tree, presumably the web presence. zeta-todo/ holds the Zeta work list mentioned earlier.

The gradle wrapper plus a spotless configuration plus a Jenkinsfile is a combination that says the project is built in CI and kept consistent automatically, which fits with a release process where the last step is a push.

Agent guidelines are part of the project, and they are strict

The README has a section aimed squarely at automated tooling, and it is unusual enough to quote in full. If you are an autonomous Agent, LLM, or other sort of development assistance tool, the project has strict guidelines on what you are allowed to do, and the README then routes you to a file depending on what you are: CLAUDE.md on the project root if you are Claude by Anthropic, and AGENTS.md on the project root for any other service.

Both files are present in the repository, alongside CONTRIBUTING.md and ISSUE_TEMPLATE.md, so the rules live where a tool will find them rather than in a wiki.

The reason to notice this is that a mod project of this size receives a large volume of automated pull requests, and a stated position on what may be done with assistance is a governance decision rather than a technical one. The word strict is doing work in that sentence, and the interesting detail is that the project addresses the question at all.

It is also a signal about the maintenance policy. A project that publishes agent guidelines is a project that expects to receive machine written contributions and has decided how to handle them.

A custom licence and a fast tag cadence

The licence recorded for the repository is a custom one that GitHub cannot classify, and the terms are in the LICENSE.md file at the root. That is worth reading directly rather than assuming the usual open source terms, since the classifier is telling you it could not map the file onto a standard licence.

The release cadence is the other thing to look at. The three most recent tags are release-4.1-487+1.21.1 published on 2026-10-05, release-4.1-486+1.21.1 on 2026-10-02 and release-4.1-485+1.21.1 on 2026-09-14. Three builds in three weeks, each with its own build number, which is the pattern of a project that ships a fix as soon as it is ready rather than on a calendar.

The repository is not archived and the last push was on 2026-10-20, so the work continues, and given the six step release process, the gap between a push and a published artefact is short.

For an end user, the practical entry point is the mod's website, since the README does not document an installation procedure for players, and the distribution platforms named in the release process, GitHub's release tab, Modrinth and CurseForge, are where a given build will actually appear. The tag naming, the signing key and the Project Zeta roadmap are the three things worth reading before you decide to depend on a specific build.

Editorial conclusion

Quark fits a Minecraft player who wants the quality of life features without a gameplay overhaul, and it fits a mod developer who wants to read how a large mod handles releases, signing and distribution. It does not fit a server operator who needs the new Minecraft version on day one, since the tags show the mod following the game's version numbers rather than leading them, and it does not fit a builder who wants Forge. Before adopting it on a server, check the tag naming to see which game version a build targets, verify the artefact with the Violet Moon signing key, and read the Project Zeta roadmap if you care whether the mod stays on Forge.

Frequently asked questions

Official sources

1. Issues
2. Project website
3. README
4. Releases
5. VazkiiMods/Quark on GitHub