Nexus
Framework updates and add-on coexistence
Distinguish add-on versions, framework versions, and runtime matching, including restart requirements and conflict handling.
Which materials match this documentation?
Each article states the applicable framework version at the top, taken from the companion template. Before release, development changes may still share a version number. Use the framework, template, and documentation supplied together; a matching version number does not make different snapshots interchangeable.
After release, obtain a complete matching release and let runtime compatibility select components. Do not choose packages by apparently newer names or numbers. A displayed documentation version does not prove public source is available.
Keep three versions distinct
| Component | What it represents |
|---|---|
| Your add-on version | The application functionality and web pages you deliver. |
| Embedded framework | The public APIs your add-on calls and their implementation. |
| Shared runtime components | The local web runtime actually loaded, matched to framework protocol and other conditions. |
Tutorial or page-style changes alone need no runtime rebuild. Displayed add-on versions alone cannot determine runtime compatibility.
Each add-on retains its complete copy
Embed nexus_web in every add-on and bind through public APIs. Runtime services coordinate sharing. Do not turn it into a separately installed shared framework or delete copies simply because multiple add-ons contain them.
Same-release copies may come from different development snapshots. Generated identities distinguish them. Do not hand-edit identities, increase numbers arbitrarily, or select providers by names or enable order.
Confirm the need before upgrading
- Check whether the desired feature is already public in your copy and what the upgrade solves.
- Obtain complete official sources for the target version and check API and runtime requirements.
- Replace through the existing update flow and synchronize the per-file manifest. Do not bypass copy-check failures.
- Check whether page helper scripts also need updating; avoid mixing versions.
- Save and restart Blender normally, then check existing entry points and operations.
Restart requirements versus identity conflicts
A restart requirement means current runtime state cannot take over disk changes immediately. Save, close, and reopen. An identity conflict means inconsistent source or generated identity; obtain matching materials and locate the conflict. Repeated opening, reinstalling, or renumbering is not verification.
Hot replacement is unsupported. Successfully updated files and a running updated service are different facts.
Use the runtime's installation flow
Use the download card for missing or incompatible components. Local ZIP installation stays offline. When Blender permits networking, installations from any source can check updates. Identical packages are not reinstalled. Historical packages without version metadata show Not recorded and let users choose a compatible installation. See Install and check runtime components.
During 0.x, only the latest official release is maintained. A successful newer release ends support for older 0.x versions; unneeded old runtime packages are removed. Formal 1.0 also retires all 0.x. Development commits, candidates, and internal tests do not trigger retirement. Components needed by the latest release remain. Ending support does not uninstall users' add-ons/components or delete source history and licensing materials.
The first release is 0.x, with no compatibility guarantee between 0.x releases or from old 0.x add-ons to 1.0. After formal public 1.0, 1.x promises both source compatibility when authors replace an older 1.x framework and coexistence when old add-ons retain their 1.x copy alongside newer add-ons and matching runtime components, without code changes or repackaging. Guarantees for future major versions, such as 2.0, are decided separately.
Even 0.x upgrades need migration, coexistence, and runtime checks; incompatible versions must not forcibly take over. Internal materials do not prove arbitrary snapshot mixing works. Report actual tested combinations; policy is not platform or historical-add-on acceptance.