Right now the version history is a linear timeline, which is great for scrubbing back, but it gets hard to navigate once a model has gone through dozens of iterations. I often want to return to a specific known-good state — a finished prototype, a “before I tried that risky change” point, a client-approved revision — but finding it means scrolling through and guessing based on thumbnails or timestamps.
What I’d like:
The ability to label or tag a specific version in the history with a custom name (e.g. “v1 prototype”, “approved for print”, “before fillet rework”).
A filtered view that shows only the tagged versions, hiding all the untagged intermediate states. This would turn the dense linear history into a clean list of meaningful milestones I can jump straight back to.
Ideally, a quick toggle to switch between the full history and the tagged-only view.
Why it matters:
This would make the version history function less like an undo stack and more like real checkpoints — closer to how branching/tagging works in version control. For anyone iterating heavily on a design, being able to mark and instantly return to deliberate save points (without losing the granular history) would be a big workflow improvement.
Once you achieve a version/stopping point, create a new body and name it whatever you want (e.g. “Client Accepted Version 1”) and put it in a folder called “Versions” or whatever. Continue with your changes. If you want to go back to a specific “version”, select the item called “Client Accepted Version 1” and look at the history. Only the history steps related to that item are shown. Select the last history item which will be the step that created that item. Now create a breakpoint at that step. Once the breakpoint is created, clearing the history selection will only show steps up to that breakpoint which is effectively your versioned model. You can remove the breakpoint at any time and then follow the same steps to view a different “version” or point in time.
It’s not perfect but it definitely saves a lot of hunting for those points in time.
But how many versions and/or for how long time do we have the versions?
And add one earlier suggestion: The ability to save a version out from the original.
(Instead of the frightful maneuver; Revert to a earlier version (loosing the local copy) duplicate the project and the reinstall the original (all to keep the version history intact.)
The workaround is only to partially achieve “tagging”. It still requires multiple steps and it would not handle any type of branching which would be necessary since the “tag” is not immutable. You can still go back and change something prior to the creation of the item that represents the “tag”. But there isn’t any restriction on how many “tags” you could have and as long as you don’t merge history, they will remain indefinitely.
Versioning is not easy. Even if they were to follow established conventions for versioning such as git, a large percentage of the user base would be totally confused. Nevertheless, I’d prefer that they add this complication in the same way I that appreciated the introduction of history/parametric features.
My comment ‘got on hold’ and got out of phase for an unknown reason. It addressed derhally’s post.
With versions, I meant the versions kept by S3Ds’ ‘Show Versions.’
I do work close to your suggested workaround, tedious but it does the job.