# Amulet's release names encode which channel you installed > The version scheme is the tell: a patch release, then two pre-releases from the same day, then a final, all within two hours. The container build makes the same distinction explicit by branching on a version prefix to pick a release, a pre-release, or a custom build. Everything about how to install this tool follows from that. **Amulet-Team/Amulet-Map-Editor** — A Minecraft world editor and converter that supports all versions since Java 1.12 and Bedrock 1.7. - Repository: https://github.com/Amulet-Team/Amulet-Map-Editor - Website: https://www.amuletmc.com/ - Stars: 2,249 · Forks: 181 - Language: Python - License: NOASSERTION - Published: 2026-09-30 · Updated: 2026-09-30 · Language: en - Canonical page: https://hysenlabs.com/projects/amulet-team-amulet-map-editor ## Installing means buying an installer, and the readme says so in one line The container route is the one the repository documents itself, and it is a clone plus one script: ```bash rundocker.sh ``` The installing section is two sentences and they matter. You purchase and download an installer for your operating system and architecture from the project's commercial site, then run it and follow the instructions. That is the primary distribution path, and the words that matter are operating system and architecture, because a Python desktop application packaged this way needs a build per platform and per processor family, and the site presumably has a matrix of them. So this is a commercial product with an open repository, which is a different arrangement from most open source tools and explains several other things in the readme. It explains why the source instructions are not in the repository. It explains why there is an installer directory at the top level. It explains why the container build is the only thing you can do for free from the repository alone. And it explains the licence field being recorded as a custom one, because a product with a commercial distribution and a source-available repository is exactly the arrangement where the licence is bespoke. If you are evaluating this for a team, the purchase is the first question, and the fact that the source is on a public forge is not the same as the source being freely licensed. ## Two source routes, and the container is the one that documents itself There are three ways to run this and they are not equal. The compiled build needs nothing, because that is the installer. Running from source has a note attached in bold capitals saying that if you are running a compiled build you do not need to do this, and then it points at the same commercial site for instructions, which is an admission that the repository does not document its own build. The container is the exception, and it is documented here: the image runs on any Linux distribution with Docker support, and to run it you clone the repository and execute a shell script at its root. That is a complete instruction, and it depends on a script being present, which it is. What the container buys you is the only reproducible environment the project offers in public. The container file is a two-stage build on a long-term-support Ubuntu release, and the stages are separated along the lines you would expect from a project that cares about image size. The first stage installs the development headers, a compiler, a GUI toolkit development package, git and a downloader, then fetches a build tool from a release page with a checksum-free installer invocation and a flag to skip its licence prompt. The second stage installs the runtime interpreter, the GUI runtime library, a desktop bus package and a notification library, and almost nothing else. That second stage is the list of what a wxPython desktop application needs at run time on Linux, and it is a reasonable place to look if a headless server complains. ## A build argument that branches on a version prefix, which explains the release names The most instructive part of the container file is a build argument that selects which version of the application to install, and the way it does it is by string inspection rather than by a version constraint. The argument defaults to a value meaning the latest release. Then a chain of branches: if the value begins with a prefix meaning a custom build, the rest of the string is treated as a pip requirement; if it is a plain release marker, the stable package is installed; if it is a beta marker, a pre-release constraint is used; if it is an alpha marker, a different pre-release constraint is used; and otherwise the value is pinned exactly. So the container can build any of four things from one argument, and a maintainer can produce a nightly image by passing a different value. That is a small, well-designed piece of build configuration. It also explains the recent release names. The list shows a patch-level tag, then two tags with a letter suffix and a prerelease counter, then the final, all on the same day, and the final's timestamp is hours after the prereleases. That is a team shipping a prerelease to a small group and then cutting the release the same morning, which is exactly the workflow the build argument is designed for. The readme adds one more distribution note: versions before a specific point are on a separate releases page, packaged as a folder with an executable to run. ## Four first-party dependencies, and a build that resolves them for you The packaging file names four dependencies as first party, which means the project treats them as its own even though they live elsewhere: a core library, a binary tag library, a translation library, and a resource pack library. Any reader wondering how a world converter works can guess the shape from those names. A core library is the object model for worlds and blocks, a binary tag library is the serialisation format Minecraft has used for its data since before the supported version range, a translation library maps between the two editions' identifiers, and a resource pack library handles the client-side art. The build configuration then does something worth reading. The build system requires a version-control-aware versioning library, a compiled extension toolchain at a pre-release version, and a numeric array library at a compatible range. The setup script has a function whose stated purpose is to make sure the source version uses the same dependencies as the compiled version, and whose comment explains the reasoning: install the requirements to find the newest compatible versions so both builds agree and neither is left on an old pin. It does that by shelling out to the installer, freezing the result, and rewriting the first-party entries in the requirement list. That is an unusual and rather thoughtful build step, and it is the kind of thing that only matters once you have both a binary distribution and a source distribution to keep aligned. ## Continuous integration for a build, a test suite and a style check Three badges sit above the title and each names a workflow: a build, a unit test run triggered on push, and a style check triggered on push. Three separate gates rather than one is a deliberate choice, because a build failure, a test failure and a formatting failure are different problems with different urgencies, and splitting them means a contributor sees which one failed. The style check as its own job is a strong signal about how the project is run, because it means formatting is enforced automatically and is not something reviewers argue about. The test suite lives in a tests directory at the top level, and there is a manifest file for packaging data. The repository also carries a file that looks like a note about the application's executable, suggesting something specific about how the packaged app is launched on each platform. The coverage claim in the readme is the one that sets expectations: all versions since a specific Java release and a specific Bedrock release, which is roughly a decade of format changes across two editions of a game that has changed its data format repeatedly. That is a large compatibility surface to test, and the readme makes no claim about which specific versions are verified in the suite. The honest reading is that the coverage claim describes the translator library's reach, and that the editor is tested against a subset. ## Conclusion Adopt Amulet if you need to convert or edit Minecraft worlds across versions or between the two editions, since supporting a decade of format changes is the problem the tool exists to solve and the readme states the coverage explicitly. Do not expect a free install, because the documented path is a purchased installer from a commercial site, the source build instructions are on that site rather than in the repository, and the container is the only zero-cost route the readme describes. Four things to verify. Which build you actually get, because the recent tags include two pre-releases from the same morning as the final, so a pre-release and a release from one day are functionally different software. That the licence permits what you intend, since it is recorded as a custom licence GitHub cannot classify and the readme does not summarise it. What the source route costs, because the build requires a compiled extension toolchain, a GUI toolkit development package, and a prebuilt wheel for one specific platform, so building it on another platform is a different exercise. And what happens to your worlds, because editing a world file in place is destructive and the readme says nothing about backups. The last push was on 2026-09-28 and the default branch is named for the release line rather than for a language. ## FAQ ### How do I install Amulet Map Editor? The documented path is to purchase and download an installer for your operating system and architecture from the project's site and run it. Running from source is documented on the same site, and there is a container route for Linux where you clone the repository and run a script at its root. ### Which Minecraft versions does Amulet support? The readme states all versions since Java 1.12 and Bedrock 1.7. That is the translator library's stated reach. The readme does not say which versions the test suite verifies, so the coverage claim and the tested set are not the same thing. ### What are Amulet's first-party dependencies? Four, named in the build configuration: a core library, a binary tag library, a translation library, and a resource pack library. The setup script treats them as first party and resolves their versions at build time so the source and compiled builds use the same ones. ### How do I run Amulet in a container? The readme says the image runs on any Linux distribution with Docker support, and to run it you clone the repository and execute a shell script at its root. The container file is a two-stage build that installs development headers and a compiler in the first stage and only the runtime interpreter, a GUI runtime, a desktop bus package and a notification library in the second. ### What licence is Amulet Map Editor released under? The repository records a custom licence that GitHub cannot classify, and the readme does not summarise its terms. Given the commercial installer distribution alongside the public source, this is a source-available arrangement rather than a standard open source licence, and the terms should be read before use. The last push was on 2026-09-28, and the default branch is named for the release line. ## Sources - [Amulet-Team/Amulet-Map-Editor on GitHub](https://github.com/Amulet-Team/Amulet-Map-Editor) - [Issues](https://github.com/Amulet-Team/Amulet-Map-Editor/issues) - [Project website](https://www.amuletmc.com/) - [README](https://github.com/Amulet-Team/Amulet-Map-Editor/blob/0.10/README.md) - [Releases](https://github.com/Amulet-Team/Amulet-Map-Editor/releases) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/amulet-team-amulet-map-editor