Here is the version graph of something I am working on today?

stevehess

Hi everyone, I just wanted to spark a conversation about the version graph. Who is using it and how? The version graph is the starting point for all (most) things 'data management' in Onshape. It tracks your versions and branches and provides an easy way to set & view the related meta-data (properties). Tell us what you tried, what you like or don't like.

Don't forget, Shift-S to save quickly a version.

Here is a pic of a version graph for a doc I am working on today.

jon_hirschtick

We REALLY need a Sample Public Onshape Document that has a nice rich version graph to show people what it is capable of. Steve: can you post one to Public?

kevin_quigley

This has the potential to make or break OS in certain heavily regulated markets where there are a plethora of startups...Im thinking medical. I cannot emphasise the importance of being able to track revisions in these areas. Currently ALL the medical companies I work with use paper based archives and it is a nightmare dealing with the regulatory requirements. Every single tweak has to be logged, explained, referenced.

Traditional CAD PDM just fails dismally at this because it is too complex, too costly and too cumbersome for small medical startups to manage, where often the in house teams have diverse backgrounds and are not process or product development specialists.

If there was a way to tie in model change logs to add date, user, supporting documentation (that might drive the change), etc and have a way of saving all that out to an archival format (paper or PDF are the preferred options) at a reasonable cost ( like the costs I have discussed with Joe) you have a winner. To some extent this is what Workbench is trying to do as well but it is not a CAD platform.

My business has moved from doing very little in medical to probably 50% medical now in the space of a few years. It has been a huge learning curve, but the fact is that most StartUps in this sector are in the same boat, having to bring in very costly consultants to advise on setting up processes. And that is all it is. Processes. I see no reason why something like OS or Workbench cannot be adapted to be a system for development to specific standards.

I have dabbled with the revisions in OS and from what I can see it has the potential to meet this workflow.

FYI we have just started moving our in house ( and extended team incorporating customers) projects to ProofHub. This was driven by customer demands for more access to development visibility. ProofHub was selected after a long series of trials. Its not perfect, but it does do most things well. The odd thing is that we find ourselves driving the adoption of these tools as the companies do not have the time, experience or knowledge of development processes required to make good judgements.

stevehess

<<repost from another forum thread>>
@JonHirschtick‌

I have shared a document called "Boat Pump Version Graph 9-30-2014" which contains a version graph with a base design and three alternative branches. Each branch has a number of saved versions (closed node on the tree) including one called "Released".

The Properties have also been set for each release including part#, description, release "state", etc. See Properties under the gear/action icon for the version. Note that "State" may only be set on a saved version. The State of a workspace is always "In Progress". All properties (meta-data) are transferred from the workspace to the version on Save.

The process for setting properties/meta-data is:
1) Set all the part/assy properties in the workspace
2) Save a version
3) Edit the properties of the saved version and set the State as necessary.

Eventually we will wrap the properties in a workflow with privileges to control changes. The properties of a version are not immutable.

This document is public as:
https://cad.onshape.com/documents/559b9a459ca348529d9f4761/w/1a1b32a12ea147c99f1a0672/e/afe404dadfb243718c9e2a15

Comments and feedback on versions is greatly appreciated.