Telling players which version your add-on needs

The primary mechanism for locking an add-on to a minimum Bedrock release is the min_engine_version field inside your pack's manifest.json header. This field takes an array of three integers representing the major, minor, and patch version of Minecraft (for example, [1, 20, 80]). If a player runs an older version of Minecraft than the one specified here, the game will refuse to apply the pack or show an incompatibility warning in the pack selector.

Beyond blocking outdated clients, min_engine_version also controls how the game parses certain components and Molang queries across your entire pack. When Mojang changes how an existing feature works without changing its JSON syntax, they check your pack's min_engine_version to decide whether to run the legacy behavior or the updated behavior. Because of this, you should always set min_engine_version to match the version of Minecraft you are actively testing against.

{
  "format_version": 2,
  "header": {
    "name": "pack.name",
    "description": "pack.description",
    "uuid": "a1b2c3d4-e5f6-4a5b-8c9d-0e1f2a3b4c5d",
    "version": [1, 0, 0],
    "min_engine_version": [1, 20, 80]
  },
  "modules": [
    {
      "type": "data",
      "uuid": "f1e2d3c4-b5a6-4f5e-8d9c-0b1a2f3e4d5c",
      "version": [1, 0, 0]
    }
  ]
}

New creators frequently confuse min_engine_version in the manifest with the format_version field found at the top of individual content files (like entities, blocks, and items). While min_engine_version sets a floor for the entire pack, format_version tells the game's JSON parser which schema rules to use for that single file.

A pack with a min_engine_version of [1, 20, 80] can still contain an entity file with a format_version of "1.16.0" if that entity does not need any newer entity components. However, you cannot do the reverse: if an individual block file uses format_version "1.20.80" to access modern components like minecraft:destructible_by_mining or minecraft:geometry, a player on Minecraft 1.20.40 will not be able to parse that block, even if you lowered the manifest's min_engine_version.

{
  "format_version": "1.20.80",
  "minecraft:block": {
    "description": {
      "identifier": "example:custom_stone"
    },
    "components": {
      "minecraft:destructible_by_mining": {
        "seconds_to_destroy": 2.0
      },
      "minecraft:geometry": "minecraft:geometry.full_block"
    }
  }
}

Relying only on min_engine_version has a major UX drawback: players often do not realize why a pack failed to load, or they download the pack on a mobile device or console without reading the download page first. The most reliable place to tell a player which version your add-on needs is directly inside the pack description, using localization keys in your language file.

By putting the required Minecraft version and any required experimental toggles on the first line of pack.description in texts/en_US.lang, the player sees the requirement in the Behavior Packs and Resource Packs menus right before they click Activate. You can use standard Bedrock formatting codes (the section sign followed by a character) to color the version notice so it stands out against the rest of your description.

pack.name=Cavern Overhaul BP (v1.2.0)
pack.description=§eRequires Minecraft 1.20.80 or newer.§r\nAdds new underground stone variants and ambient cave features.

If your behavior pack uses JavaScript and the Script API, there is a second version gate that is much stricter than min_engine_version. In your manifest.json dependencies array, you declare modules such as @minecraft/server with a specific version string like "1.10.0" or "1.11.0-beta".

Stable script module versions (such as "1.10.0") are backwards-compatible with newer releases of Minecraft; a pack requesting 1.10.0 will continue to run on Minecraft versions that ship with 1.11.0 or 1.12.0. However, if you use a "-beta" version string, your pack is locked to the exact minor release of Minecraft that supports that specific beta API. The moment Minecraft updates to the next minor version, the beta API version increments and your pack will completely stop running scripts until you update the manifest. Always tell players in your pack description if your pack relies on the Beta APIs toggle, as they must expect it to break on the very next game update.

{
  "format_version": 2,
  "header": {
    "name": "pack.name",
    "description": "pack.description",
    "uuid": "11111111-2222-4333-8444-555555555555",
    "version": [1, 0, 0],
    "min_engine_version": [1, 20, 80]
  },
  "modules": [
    {
      "type": "script",
      "language": "javascript",
      "uuid": "66666666-7777-4888-8999-000000000000",
      "entry": "scripts/main.js",
      "version": [1, 0, 0]
    }
  ],
  "dependencies": [
    {
      "module_name": "@minecraft/server",
      "version": "1.10.0"
    }
  ]
}

When players join a multiplayer world or Realm, they never see the world creation screen or the pack activation list. If your resource pack or behavior pack requires a minimum version or specific settings, joining players might experience missing textures or broken mechanics without knowing why.

If your pack already includes a script module, you can send a private chat message or action bar prompt to players when they spawn, reminding them of the version the pack was built for. While a script cannot read the client's exact game version number directly, printing the add-on's version and target Minecraft release on first spawn helps server owners and players diagnose mismatches immediately when someone joins on an outdated client.

Applies to all modern Bedrock Edition versions using manifest format_version 2 (1.13.0 and newer). No experimental toggles are needed to set min_engine_version or localized pack descriptions.

Read out of the game itself, so the ids match the version you are building for.