Skip to content

Releases

A release is an immutable snapshot of plm-data/ at a point in time, tagged in Git. Once a release is cut, the bundle of parts + BOMs + ECOs as of that tag cannot change. Future edits land on main and on follow-on releases.

Why immutability matters

When you cut a purchase order, fab a PCB run, or hand a BOM to a contract manufacturer, you commit a specific configuration to the physical world. Months later — when something fails in the field, or you need to reproduce the build, or auditors come knocking — you need an exact record of what you actually built, not what main happens to look like today. Releases provide that anchor.

What gets bundled

A release contains:

  • Every parts/<pn>/part.yaml file at the tagged commit.
  • Every boms/<pn>.yaml file at the tagged commit.
  • Every ecos/<id>.yaml file whose state: released and whose merge commit is an ancestor of the tag.
  • A generated release.yaml manifest listing the included artifacts and their content hashes.

Attachments (datasheets, 3-D models) are referenced by content hash so they too are immutable.

Creating a release

Releases are cut from the dashboard’s Releases tab or via plm releases create. The flow is covered in Review and release.

Naming

Use whatever versioning convention your team prefers — semver (v1.2.0), build numbers (2026-Q2-B17), or date strings. simple-plm doesn’t enforce a format; it does require uniqueness.

See plm releases for the CLI surface.