Structure of manifest

Anki allows sharing add-ons outside AnkiWeb. The add-on must have a manifest.json file in the top directory and be zip-compressed into a file with an .ankiaddon extension (though I believe that having the default .zip extension also works).

According to the docs the package and name fields are required, and the conflicts and mod fields are optional. There are also a couple of fields not specified in the docs, but which can be sleuthed by inspecting Anki's source code.

Here's a maximalist example of how our (CrowdAnki) manifest.json could look (this had been tested to work as of 2023-01):

{
  "package": "crowd-anki",
  "name": "CrowdAnki",
  "mod": 1675154545,
  "conflicts": [],
  "min_point_version": 50,
  "max_point_version": 57,
  "human_version": "v0.9.3",
  "homepage": "https://github.com/Stvad/CrowdAnki/"
}

Note that a positive max_point_version does not indicate maximum 2.1.x compatible Anki version, but the highest version tested. (A negative max_point_version indicates maximum compatible Anki version.)

If we ever have beta builds, the conflicts field could allow the release builds to conflict with the beta builds (and vice-versa), to allow users a way to quickly and easily switch.

The manifest.json settled on (2023-05) was this:

{
  "package": "crowd-anki",
  "name": "CrowdAnki",
  "conflicts": [],
  "min_point_version": 50,
  "homepage": "https://github.com/Stvad/CrowdAnki/"
}

mod and human_version could be added automatically during release, with date "+%s" and git describe.