

The addon should have the _init_.py file and relative code structure at the root of the repository, not in a sub folder.in _init_.py: “version”:(1,0,1) will get paired with a git release/tag title of “1.0.1”, “v1.0.1”, “1.0.1 release” or similar such naming structures. The blender bl_info versions should match the git release version.containing an _init_.py file and support files included in the same zip file for installing, as opposed to self-contained addons installed as a single python file. While these are not covered in this tutorial, see example usage of releases here (tags are a feature of all git repositories, so it works the same on GitHub, GitLab, and Bitbucket but perhaps with different website UI). To make full use of the features, you should be using git tags/releases.Private repository support for GitHub and bitbucket is planned.

There is also current support for private GitLab repositories. Currently, your project must be hosted in GitHub, GitLab, or Bitbucket as a public repository.Configurable in many ways, such as to only notify users of updates without permitting one-click installation.If enabled, allow for directly updating to the git Master code/another branch at any time.Allow the user to install old versions of the addon, and revert back to backups after updating/reverting.Allow the user to directly update to a version with a single button click.Notify the user of an update (via popup notification on startup).Check for updates in the background after intervals of time.The updater allows an addon installed in blender to:


Note this is outdated and only covers GitHub repos, but the content is still valid See also the recent announcement on the importance of updating. This addon updater module is used in RetopoFlow, Crowd Master, MCprep, and soon even more blender addons.
