STL File Versioning for Production Products

Version an STL product as if its physical interfaces are a public API. A patch fixes geometry without changing fit, a minor release adds a compatible option, and a major release breaks compatibility with an earlier mating part, accessory, assembly method, or customer promise. The exact numbering convention matters less than one rule: once a release reaches production, never replace its contents silently.

This is a production-control system, not a clever file-name system. It should let a seller answer four questions in seconds: What did this customer order? Which source produced it? Which other parts fit it? Which revision should fulfill a replacement?

Define the product's compatibility contract

Before numbering files, list what downstream users rely on:

• overall envelope and mounting locations;
• mating diameters, slots, tabs, and fastener sizes;
• snap-fit or press-fit behavior;
• assembly sequence;
• accessory compatibility;
• material and orientation assumptions;
• package or insert requirements;
• visible finish promised in the listing;
• storefront SKU and variant meaning.

Those facts are the product's public contract. A decorative fillet change may leave it intact. Moving a mounting hole does not. Changing a base so an old lid no longer fits is a breaking change even if both files still slice.

The Semantic Versioning specification defines major, minor, and patch changes around a software public API and requires released contents to remain immutable. STL products are not software packages, but the model translates well when “public API” means physical and commercial compatibility.

Use an immutable release layout

Create a release folder rather than dropping files into one growing directory:

desk-stand/
  releases/
    1.4.2/
      desk-stand_body_1.4.2.stl
      desk-stand_insert_1.4.2.stl
      manifest.md
      changelog.md
      preview-front.jpg
      approval.txt
  working/
    desk-stand_body_NEXT.step

The released STL name includes the product, component, and version. Variant attributes belong in the name when they alter geometry:

desk-stand_body_large_left_2.0.0.stl
desk-stand_body_large_right_2.0.0.stl

Do not encode every slicer setting into the filename. Put production requirements in the release manifest and controlled production configuration. Long names encourage truncation and transcription mistakes.

Make the manifest the release's source of truth

Each release manifest should record:

Include a checksum for each exported STL if your tools make that practical. A checksum distinguishes two files with the same visible name and detects an accidental re-export.

The manifest should point to the editable source without pretending the STL is that source. Keep CAD, parameters, and export instructions under version control. An STL is a manufacturing handoff artifact; it is a poor place to recover design intent.

Write changelogs for operators, not historians

A useful entry describes the physical effect, compatibility, and required action:

1.4.2 — Increased cable-channel roof thickness near the rear bend. No exterior, mounting, packaging, or accessory changes. Existing 1.x bodies and inserts remain compatible. Re-sample the rear bridge before production.

A weak entry says “fixed model.”

Use four fields:

1. Changed: the geometry or document that moved.
2. Reason: failure, request, cost, or capability that triggered it.
3. Compatibility: what old and new parts can be mixed.
4. Action: sample, listing, SKU, inventory, or instruction updates required.

Write the entry before approval. If the designer cannot explain compatibility, the release is not ready.

Choose patch, minor, or major by customer impact

Use this decision tree:

• Does the new part fail to mate with an old complementary part? Major.
• Does an old accessory or replacement stop fitting? Major.
• Does the listing need a different size, use, or assembly promise? Usually major or a new SKU.
• Is there a new optional component that preserves every existing interface? Minor.
• Does the geometry correct a defect while preserving interfaces and expected behavior? Patch.
• Is it only a source-document or instruction correction with identical manufacturing geometry? A document revision may be enough; do not re-export just to increase a number.

Version numbers communicate impact, but they do not replace a compatibility table. Maintain explicit rows:

Separate file versions from storefront SKUs

A SKU identifies what the customer buys. A file version identifies how that promise is produced. Several compatible patch releases can fulfill the same SKU, but a breaking product revision may require a new SKU or a deliberate listing transition.

Never rename a storefront SKU casually just because a file changed. Order history carries the old SKU, and integrations depend on exact values. Instead, maintain a release mapping:

Shopify's SKU guidance recommends unique and consistent identifiers and warns that missing or mismatched SKUs cause third-party sync issues. Preserve that stability while versioning the production artifact behind the SKU.

Run a release gate

Every production release should pass the same sequence:

1. Freeze the candidate source and export settings.
2. Verify units, watertight geometry, component count, and orientation.
3. Compare the candidate with the prior release.
4. Update manifest, changelog, and compatibility table.
5. Print the smallest sample that exercises every changed risk.
6. Assemble with current and, where claimed, prior compatible parts.
7. Test packaging and instructions if dimensions or assembly changed.
8. Record approval and immutable file checksums.
9. Schedule the storefront-to-production cutover.
10. Preserve the previous release for open orders, replacements, and rollback.

Do not approve a geometry change from slicer preview alone. A file can be valid and still produce a weak interface, trapped support, rough customer-facing surface, or incompatible assembly.

Reconcile open orders during cutover

At release time, create three sets:

• Unstarted orders: may move to the new release if the customer promise remains compatible.
• Work in process: usually finish on the version already issued to production.
• Replacement or support cases: reproduce the historical version unless the new one is explicitly backward-compatible and the customer will receive every affected mating part.

This is why deletion is dangerous. An old file may have no new sales but still be required to make a matching replacement.

If a safety, compliance, or severe functional defect makes an old revision unacceptable, treat that as a formal containment decision. Identify affected orders, stop the old configuration, and determine replacement scope instead of quietly swapping the file.

Apply the system in Printie

Printie maps storefront SKUs to active design configurations. When a source file changes, coordinate the replacement and review rather than uploading “final-final.stl” as an unrelated mystery file.

A safe handoff includes:

• the versioned source filename;
• a changelog summary;
• affected SKUs;
• compatibility decision;
• changed acceptance checks;
• cutover order or date;
• instructions for open orders and reprints.

After the new source passes the applicable review and sample gate, update the active production mapping. Keep your own immutable release archive even if a provider stores the current file; it remains your product-history record.

The related SKU mapping guide explains how the sellable identifier resolves to designs, quantities, and materials. For the broader production handoff, see How Printie works.

Release audit

• Published releases are immutable.
• Every file name includes product, component/variant when needed, and version.
• A manifest records units, components, requirements, SKUs, and approval.
• Changelog entries state physical impact and compatibility.
• Breaking fit changes create a major version or a new sellable SKU.
• Compatibility is a table, not an assumption.
• Every candidate is physically sampled against changed risks.
• Open orders have an explicit version decision.
• Historical files remain available for replacement and rollback.
• Printie's active SKU configuration matches the approved release.

Versioning earns its keep on the first urgent replacement, rollback, or fit complaint. Build it before the catalog is large enough that “which final file?” becomes a customer-facing question. When the release system is ready for outsourced production, compare the operating path on Printie pricing with the product's actual components and material choices.