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.yamlfile at the tagged commit. - Every
boms/<pn>.yamlfile at the tagged commit. - Every
ecos/<id>.yamlfile whosestate: releasedand whose merge commit is an ancestor of the tag. - A generated
release.yamlmanifest 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.