Naming and versions

Naming conventions and version control for 3D print files

Updated Aug 10, 2026 · 8 min read

Every 3D printing library eventually produces a file called something like dragon_v2_supported_final_FINAL.stl. It is a joke everyone recognizes, and it is also a real failure: the name is the only place the version information lives, so it grows until it is useless. This guide covers a naming convention that stays readable, how to track versions without a version control system, and how to rename a library you already have without turning every rename into a duplicate.

Filenames do too much work in 3D printing. A single string has to say what the model is, which variant it is, whether it has supports, which printer it was sliced for, and how recent it is. Nothing else in the workflow records any of that, so it all ends up in the name, and the name collapses under the weight.

How names collapse

The pattern is always the same. A file starts as dragon.stl. You export a supported version, so now there is dragon_supported.stl. The creator posts a fix, which becomes dragon_v2.stl. You scale it for a smaller printer and get dragon_v2_small.stl. Somewhere in there a file gets marked final, and then something changes, and final_FINAL is born.

Three specific things have gone wrong, and they need different fixes:

• Ordering is lost. Nothing in v2, final and FINAL tells you which came last. Only the file modification date does, and that is destroyed by copying files between drives.
• Variants and versions are mixed. Supported and small are variants that coexist; v2 is a version that replaces v1. Putting both in the same string means you cannot tell which files are alternatives and which are obsolete.
• Nothing carries context. Why v2 exists, what was wrong with v1, and which one you actually printed successfully all live in your memory, and only briefly.

A naming convention that survives

A good convention is short, sorts correctly, and never needs to be edited after the fact. Four rules get you there:

1. 1Lead with the model name, unchanged from the creator. It is your link back to the store page and to any instructions, and it makes the file findable by the name other people use for it.
2. 2Use ISO dates, not version numbers, when you need ordering: dragon_2026-03-14.stl sorts correctly in every file manager on earth and needs no key to interpret. Version numbers only work if you never lose count, and everyone eventually loses count.
3. 3Put variants in a fixed position with a fixed vocabulary. Pick supported or unsupported, pick one word for scale, and always use them in the same order. dragon_supported_75pct is readable; dragon_75_sup_fix is not.
4. 4Never write final, new, latest, or fixed. Every one of these is true only at the moment you type it, and each becomes a lie within a week.

Applied consistently, this produces names like wyrm_supported_2026-03-14.stl. It sorts chronologically, it says what variant it is, and it will still make sense in two years, which is the only real test.

Versioning without a version control system

For a printed model, the thing you actually want to remember is not the sequence of edits. It is which file printed successfully, on what machine, with what settings, and what went wrong with the ones that did not. That is a note, not a commit history.

This is where the filename should stop growing and a separate layer should take over. Keep the successful version under a stable name, and record the context somewhere it can be searched: what failed, which printer it was for, which material it was sliced for. Meshory keeps per-model notes and filament assignment alongside the model, and tags such as printed, failed or needs-supports turn status into something you can filter the whole library by rather than something encoded in a filename.

The general split, with folders holding location, tags holding properties and collections holding intent, is set out in the three-layer system. Version status belongs firmly in the tag layer.

Should you use Git for STL files?

For your own parametric designs, sometimes. For a downloaded model library, no. Git stores a full copy of every version of every binary file, so a repository holding a few hundred STLs grows without bound and every clone carries the entire history. Git also cannot show you what changed between two versions of a mesh, which is the one thing a version control system is supposed to be good at.

There is a narrow case where it works: source files for designs you author yourself, particularly text-based formats like OpenSCAD, where diffs are meaningful and file sizes are small. Keep the source in Git if you like, and treat the exported STLs as build artifacts that live in your normal library.

Renaming a library you already have

Applying a new convention to thousands of existing files is where naming projects go wrong, because the obvious approach creates exactly the problem it was meant to solve. Copy a file to its new name and delete the original later, and for a while you have both. Miss one deletion and you have a permanent duplicate that no filename search will ever connect to its twin.

1. 1Deduplicate first. Renaming a library that still contains copies means renaming the same model several times, and it hides the copies behind new names. Run a content and geometry pass first with a duplicate finder.
2. 2Rename in place, never copy-then-delete. A true rename is atomic. A copy is a second file that exists until you remember to remove the first one.
3. 3Rename through a tool that keeps your metadata. If tags, notes and thumbnails are keyed to the path, renaming throws all of it away and you rebuild from scratch.
4. 4Leave creator files alone unless you have a reason. Their names are your link back to the source, and a personal convention rarely justifies losing that.

Meshory renames the real file or folder on disk and updates the library entry in the same step, so tags, notes, collections and thumbnails all carry over, including when you rename a folder and everything inside it. It validates names against the rules of every platform your library touches, so a name that would break on Windows or on a NAS share is refused while you type rather than discovered later. It also refuses to overwrite an existing file instead of silently replacing it. The specifics are in renaming files and folders.

What to do instead of renaming

Worth asking before a mass rename: what are you actually trying to fix? Usually the answer is that you cannot find things and cannot tell what a file is. Renaming is an indirect fix for both, and an expensive one.

Search across names, paths, tags and descriptions solves findability without touching a single file. Rendered thumbnails solve identification better than any filename can, because you see the model rather than a description of it. Between them, most of the pressure to rename disappears, and the naming convention becomes something you apply to new files going forward rather than a project you run against ten thousand old ones. The whole system this fits into is the complete guide to organizing an STL library.