layersClean Panels7.0.7→8.0.0DownloadChangelog
Stop writing an updater for every add-on you ship. Register an ID, publish a version, and every user running the LEUC master add-on hears about it the next time Blender opens.
What your users see, inside Blender
Every add-on that ships its own updater duplicates the same network code, the same version parsing, and the same failure modes. Users end up on old builds not because they refused an update, but because nothing told them.
See how LEUC handles itA free launcher for the other half of the problem: the versions themselves. It finds every Blender you already have, installs new ones from blender.org in a click, and opens each file in the version that made it.
The master add-on collects every installed add-on ID and version in one pass. No per-add-on network code.
Publishing a version writes a static manifest to the edge. The check reads those, cached, and never has to reach the database.
The module does the semantic comparison itself, and keeps only what changed: latest version, update type, changelog, download URL, criticality.
A notification inside Blender, with the changelog attached. One click to the download. Nothing to configure.
# blender 5.2 · master add-on 1.4.0$ leuc scan --installed found 4 add-ons GET /addons/cleanpanels.json{ "addon_id": "CleanPanels", "latest_version": "7.1.0", "update_type": "minor"} 4 files · edge cache · 38 mscompared locally CleanPanels 7.0.0 → 7.1.0 minor NGonLoopSelect 3.0.0 → 4.0.0 major · breaking → 2 notifications shown in Blender
Every release writes this to the edge. The add-on reads it and compares locally, so a routine check costs a cached file and never touches the database. A REST endpoint exists too, for anything custom.
{
"addon_id": "cleanpanels",
"latest_version": "9.2.3",
"update_type": "patch",
"is_critical": false,
"changelog_url": "/addons/cleanpanels/changelog"
}Claim the ID once and it is bound to your account. Nobody else can publish a version under it, and users can verify who shipped what.
Version spread, adoption after a release, and the Blender versions your users run. Enough to decide when a legacy branch can be dropped.
Users file a report from inside Blender — the traceback redacted on their machine and again on arrival, no account, no email. Point an add-on at a Discord webhook and every report lands in the channel the moment it does. Answer in the thread; they read your reply in the same panel they filed from.
#addon-support Project LEUC APP Bug report - CleanPanels AttributeError: 'NoneType' object has no attribute 'panels' File "/home/<user>/.config/blender/addons/cleanpanels/core.py", line 88 Ticket leuc-K4TQ-8ZP2WM1X-3RV0DCEA · Blender 4.2 · v9.2.3 Click the title to triage this report
Drop the module in and register it. It handles the request, the cache, the backoff, and the notification UI.
# __init__.py from . import addon_update_checker def register(): addon_update_checker.register()
Claim your ID in the dashboard. It is checked against the registry, so collisions are caught before your first release.
Push the version, changelog, and download URL — from the dashboard or the API. Mark it critical if users must take it.
Adoption shows up per version. You see how fast a release spreads and who is still on the old build.