Versioning Philosophy in Onshape

owen_sparks

@StephenG

Element level "versioning" exists in Onshape, it's just termed "revisioning" and is part of the paid subscription tier under the "release management" features.  It's been discussed throughout this thread...  So your question should really be "Why is element level versioning not available in my free level of the software?"

As for document level versions I'd image the move to a single database as opposed to individual files has a lot to do with it.

Cheers, Owen S.

philip_thomas

I would go one step further than Owen and say that Revision management goes way deeper than the element (tab) level. 

Any part, any assembly, any drawing and any blob may be Revision managed. Moving forward, we are working on a mechanism to allow even finer resolution at the Part Studio level (think curves and surfaces).

• Versioning is a Document navigational tool. It has nothing to do with Revisioning
• Revisioning (Release Management) is the mechanism by which a company controls the milestones whereby the fit, form or function of a part changes. In addition, it provides the rigor of an audited approval process as required by any governance (eg ISO9000, FAA, FDA, MDD etc)

This is a very simple distinction. Saying that Versioning doesn't work for Revision Management or Release Control, is like saying "this spatula makes for a very poor car"!

We are continuing to add capabilities and rigor to Release Management - you recently saw new options for suppressing watermarks on drawings of non-rev managed parts/assemblies and we are working on a slew of other workflow enhancements to streamline the submit/reject/change/re-submit workflow. We read these threads to glean how professional users would like us to enhance the capabilities of Onshape and to the community's credit, has done a pretty good job of making the product better. Please keep the enhancement requests coming

Thank you !!!  

owen_sparks

Thanks @philip_thomas

O.S.

Michael_Coffee

To expound on what @owen_sparks is saying, we can compare Onshape's Versioning to, let's say, SolidWorks PDM. While I haven't used the PDM myself (so if I'm about to say something wrong coming up, someone please correct me), from my understanding, the structure is such that most everything will be a "read-only" copy until one checks the part out to make edits. For manufacturing, it can be set up so they only have access to the released versions of it.

In having these individual files, whether they're parts or assemblies, there will be other information relevant to them, whether it's a data table, pictures, video, and this information will be stored separately from SolidWorks itself. This information will not have versions and could, unfortunately, be lost or overwritten by someone who happened to click something at the wrong moment, or have a computer meltdown that crashes something (i.e. An IT horror story told to me once dealt with a company and a hurricane. They left to escape the hurricane and it destroyed the building. All of the backups were gone because the "hurricane proof" safe was torn apart like butter. Still makes me cringe). Each file exists by itself, but not all are versionable (i.e. excel). If I had to guess, the structure of documents was set up to offer the ability to combat this issue by allowing these files to be saved to Onshape.

By themselves, these points don't address the question. However, let's imagine a "what-if" scenario. If each tab in a document was "versionable", what would be the difference between a tab and its document? Would we be dealing with documents as we understand it now, or would we be managing files disguised as tabs? If tabs were versionable, why version a document? And why version a tab that inherently won't change? (i.e. a picture) The other part of the structure change would also eliminate a vital feature of Onshape. If tabs are versionable, we would no longer be able to show changes immediately in one tab and have them appear in another (i.e. modify one part that appears in an assembly in the same document). Let's say this happened: If this elimination isn't desireable, how would one address fixing it? The only follow-up solution I can think of right now is to make those tabs not version controlled, but this is ultimately not what we want. We cannot release parts if no management of its releases exist in the first place.

Some of these questions are ones I've asked myself in the past when it comes to Onshape and each instance, I conclude the current document structure, while not easy for some company systems in how they do things, is the simplest it can be. And simple is what you need when it comes to data management. If your process cannot flow easily from one state to the next, there is waste somewhere, whether its your time, your space, or someone else's. And waste will trickle down ultimately to the people who pay our checks: the customers.

I think I've gotten off topic again. I'll wrap with a question. In my mind, the question isn't simply a "why" is versioning at the document level better. Trying to convince anyone of the merits of it is a sales position. The structure speaks for itself, which we have talked plenty about. The question is "How can we make it better?" At the end of the day, I have a list of features I want Onshape to implement. I've made only a few improvement requests in that endevear, because honestly, doing the research to make sure the improvements are needed is exhausting. Many of them probably are needed, but everything takes time, and I will do what I can to make it better. I just don't think tab versioning is the way to do it.

c_harsha

@Michael_Coffee Version and revision are completely different. You are mixing capabilities of revisioning (release management) with versions. Versions are just time stamp of the document you are working on. Problems start to arise when we try to utilise Versions to do tasks of release management. Check the comment above from @philip_thomas . He explained the same there.

In the start, I was confused a lot between versions and revisions. But after a while, I realised versions are just time-stamps (like 'save' in traditional CAD softwares). Can someone from Onshape just throw light on this, 'why did you come up with word VERSION for this time-stamp? '. In most companies, 'version' and 'revision' mean same thing, i.e. revision in Onshape. Lot of confusion I have had gone away, when I stopped to think Versions like revisions (in Onshape language), rather I use versions to just time-stamp my work, which I feel might be important to come back to or refer to or etc (kind of like 'save'). I also use Version (like Version BOSCH, for example to state its design is supplied by BOSCH)  for standard parts (have like one assembly or part and a drawing) from my suppliers, which are not release managed, thus don't have releases. So, I don't see point of having seperate versions for each tab, rather this will make workflow more cumbersome.

But I still face some problems with release management though. We need a release workflow view in a document. More clear part number visibilty and release number metadata visibility inside a document. This will help design teams and management teams a lot. I still use one document for one project or for one machine in a big project, which I also believe is better way at file management using Onshape. 

Just to add to this why comparing Onshape data management to traditional CAD tools doesn't give complete picture, I will explain a bit of my experience. My previous experience in CAD and PLM just comes CATIA V5 only and related PLM softwares from Dassault Systems (and we can agree to some extent they are leaders in this market). So, I can't really comment when people really talk about Solidworks or Inventor, etc. But I can say this from my experience when I worked in one of the biggest automobile companies in India as Design Engineer in Production Engineering, my biggest fear always come just before I release my design for production. While uploading project into PLM vault, I have make sure all part numbers, etc. etc. or other meta data are not mis-spelt. If there was any mistake during this upload, its painstakingly hard to delete the file in the vault and re-upload it. Sometimes, the links gets broken during upload. And by any chance if a part (or drawing) is missing (mistakenly) from the vault, the technicians from shop floor will make sure you will not make this mistake again, they will complain to your departement head or you get a call to visit respective shop floor and the moment you get there you will see deputy managers or some higher management officers waiting for you. I remember, during end of every month (or week), everyone in my team frantically uploading all released designs into the vault, as they didn't want to go through this pain just after they finished the design and just used to post-pone until deadline comes near. And the moment I switched to Onshape (for my startup), versioning and release management in Onshape actually made me not worry about these problems, but I had very rough start to Onshape. Yes, I have listened to their tutorials and attended their classes, but until I ditched my previous notion on how CAD software works, I didn't have clear understanding of Onshape. 

I suppose, if Onshape can do a video explaining differences between versions and revisions using some case studies of industrial projects, most of the doubt users have will be answered.