--- title: "Releases" description: "Immutable snapshots tagged in Git — your audit and reproducibility anchor." --- 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//part.yaml` file at the tagged commit. - Every `boms/.yaml` file at the tagged commit. - Every `ecos/.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](/docs/workflows/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`](/docs/cli/releases/) for the CLI surface.