BDS · Current Working Version · 0.1.0

Blender Deployment Workflow

The current working system model for deploying FH packages from the GitHub source of truth into local Blender runtimes.

System state

Purpose

The Blender Deployment System bridges the online 2HE repositories and local Blender runtime installations. GitHub remains authoritative for code, package metadata, versions, dependencies, and deployment definitions. Local Blender installations are deployment targets and runtime environments, not competing source repositories.

Target workflow

GitHub (SSOT)
      ↓
BDS detects Blender and packages
      ↓
Resolve dependencies and changed sources
      ↓
Synchronize, enable, record runtime state
      ↓
Blender starts → FH__MEP runs

Operating principle

GitHub / Online SSOT

Owns source code, manifests, registry, versions, dependencies, release or commit sources, deployment definitions, and current architecture documentation.

BDS

Discovers packages, detects the Blender environment, resolves dependencies, plans changes, synchronizes packages, manages add-ons, and maintains runtime state.

Local Blender Runtime

Executes deployed add-ons and contains runtime copies, configuration, and state. It never acts as the authoritative development source.

No ZIP files, manual copy and paste, add-on-directory searches, or competing local development SSOT.

First end-to-end milestone

  1. BDS discovers FH__MEP in the GitHub SSOT.
  2. It identifies the package version and checks Blender compatibility.
  3. It installs and enables the add-on.
  4. It records the resulting runtime state.

Expected result: version detected from package metadata, installed, enabled, and traceable to the GitHub SSOT.

Initial BDS components

Evolution rule: this is not a final specification. Update it when implementation improves the architecture, preserve meaningful changes in Git history, and increment the CWV version.