A designer saves a file. A project engineer uploads it. A converter creates STEP and GLB outputs. A reviewer adds a comment. These are four events, but they do not necessarily represent four design revisions.
Lightweight file history works best when it separates the source snapshot, the engineering label and the derived artifacts. You do not need a full product-data-management system to make that distinction.
Use versions for saved snapshots
A version identifies a specific saved state: the source file, its dependencies, selected configuration and the information needed to reopen that state. Once shared, it should not quietly change underneath the same identifier.
Onshape's version model illustrates the distinction between immutable versions and active workspaces. Versions and history. A file-based service can use a simpler model while keeping that same clarity about what a reviewer saw.
If an old version is deleted under an explicit retention policy, its links should report that state. They should not silently redirect to a newer version.
Use revision labels according to the real process
Rev.A, Rev.B or a drawing issue number carries meaning within the organization's engineering process. The site should allow an explicit label without pretending it knows when a design has been approved.
An internal counter such as V1, V2 and V3 can track uploads. Keep it distinct from the user-entered revision label. An upload note saying “moved the mounting hole” is an author's description, not proof that an algorithm detected that change.
| Record | Example | What caused it |
|---|---|---|
| Source version | V2 | A new source snapshot was uploaded |
| Engineering label | Rev.B | Assigned by the responsible workflow |
| Export artifact | V2 → STEP | A conversion of that snapshot |
| Calculation record | V2, density input changed | A new analysis with recorded parameters |
This is an example convention. Existing organizational naming and approval rules should take precedence.
Do not create a new design version for every export
A STEP derivative and a preview image can both belong to V2. Rebuilding a preview after a display-engine update should not turn the part into V3. Store the producing engine, settings and date with the artifact instead.
The same applies to a mass estimate. If the geometry is unchanged but a density assumption changes, record a new calculation. Do not describe the event as a detected geometric modification.
A file hash can identify identical bytes, but different bytes do not prove different geometry. A re-export can alter ordering or other representation details without changing the intended shape.
Freeze assembly dependencies too
A snapshot of only the top-level file may be insufficient if referenced components are later replaced. Store or identify the component versions needed to reopen the same assembly scope.
Two files with the same basename can still be different component definitions. Preserve paths and identifiers where the reading workflow needs them. Keep unresolved references visible rather than creating a clean-looking but incomplete historical view.
Bind comments and comparisons to their source
A note placed on V2 belongs to V2. A later version may split a face, remove a feature or use another topology. Moving the marker automatically without a verified mapping can turn a precise comment into a misleading one.
For a comparison, save both version identifiers, the scope and the display or analysis settings. Keep a screenshot for context, but do not rely on the screenshot alone when someone needs to reopen the result.
Make history readable, not ceremonial
The useful history view answers: what was uploaded, what changed according to the author, which files were produced and which version was sent to whom. It should not claim audit certification or manufacturing approval merely because it has a timeline.
For a small team or occasional task, that simple separation prevents a great deal of confusion. The fixed-version sharing guide shows how to carry the same idea into external links.