Welcome to the Onshape forum! Ask questions and join in the discussions about everything Onshape.
First time visiting? Here are some places to start:- Looking for a certain topic? Check out the categories filter or use Search (upper right).
- Need support? Ask a question to our Community Support category.
- Please submit support tickets for bugs but you can request improvements in the Product Feedback category.
- Be respectful, on topic and if you see a problem, Flag it.
If you would like to contact our Community Manager personally, feel free to send a private message or an email.
Comments
Just thinking out-loud again here. I just want to consider the 2 extreme ends of my example above..
At stage 1 everything is live, showing the MAIN state.
At stage 8 all Assys and drawings are showing released data. (to avoid bumping elements that have not changed and the accompanying Spanish Inquisition)
Say I want to edit Prt1, check the changes and finally revision bump anything affected.
At stage 1, no problem! ...
1. Make the changes to Part1.
2. View the live changes in Assy1 & Assy2.
3. If happy, release everything from the same candidate dialog.
(Okay yes, I glossed over the fact we have to hit the "update" button on all affected drawings which is still annoying to do at early stages of a design!)
However if I'm at stage 8 it would be more like the following..
1. In Assy1 (not explicitly shown in my diagram) change the released instance Pt1_a to the live instance Pt1(main)
2. In Assy2, change the released instance Assy1_a to the live instance Assy1(main)
3. Do my edits to Pt1 and jump between Assy1 & Assy2 to check the changes.
4. If happy with the changes, release Pt1 (will bump to Pt1_b) from the PartStudio (PrtStud1)
5. In Assy1, change the live instance Pt1(main) to the released instance Pt1_b
6. Release Assy1 (will bump to Assy1_b)
7. In Assy2, change the live instance Assy1(main) to released instance Assy1_b
8. Release Assy2 (will bump to Assy2_b)
Now for the drawings. Open all affected and update to latest (rev b for each)...
9. Open d(Pt1) and Update to latest. All views now show Pt1_b
10. Open d(Assy1) and Update to latest. All views now show Assy1_b
11. Open d(Assy2) and Update to latest. All views now show Assy2_b
12. Finally, re-release the drawings, including all three above to the release candidate: d(Pt1), d(Assy1) & d(Assy2)
Phew!
Then I get a call from the shop floor requesting a change to part 2! Okay this is not fun anymore!
I'd prefer to start from the following situation:
Everything in the workspace is live (MAIN) even though all parts, assemblies and drawings have been released (all at rev A say) .
I use the same simple workflow as before...
1. Edit Prt1.
2. Check live changes.
3. Release all affected assemblies and drawings from the same candidate.
BUT this time it's different..
A. Onshape can somehow "see" that Parts Pt2 & Pt3 have not changed and so doesn't bump them.
B. Onshape can somehow "see" that drawings d(Pt2) & d(Pt3) have not changed and so doesn't bump them.
After all, the ONLY reason I'm going through the rigmarole of the 12 step process above is to prevent parts, drawings and drawings from being bumped unnecessarily. And the changes to Pt1 don't affect Pt2 & Pt3 even though they are in the same part studio.
I do realise that if I had Pt2 &Pt3 in separate part studios, then they wouldn't get bumped along with Pt1. But let's say that for this example, I do need them all geometrically linked in the same part studio and the edit to Pt1 doesn't affect its siblings.
Taking this idea further...
How about if Onshape's intelligence to "see"could extended to the following scenario...
1. Release a part. (Tube_rev a)
2. Edit the part to, say, increase its diameter. (without releasing anything yet - just trying it out)
3. For some reason we don't like the change and edit back to the original diameter.
4. When we try to release the part again, Onshape compares and "sees" no difference. Onshape tells me "Hey, this is now the same as rev A! Are you sure you want to bump the revision? Don't worry, there's been no releases since rev A, so there should be no confusion!"
That is certainly one of the issues.
The other major issue under discussion here is how the releases flow through/propagate (or don't) in the document. For example, an assembly of 5 parts is released by one designer. Another then goes to make a change to one part and release the assembly with the one updated part. The release would try to revision the other 4 parts and the designer does not know whether or not they truly changed without doing some investigating. This could result in all 5 parts being released at a new revision when only one truly had a change.
CAD Engineering Manager
Can't help but get a bit irritated...
CAD Engineering Manager
In that thread, @adrian_velazquez made a really good point about the default view of a document being the main workspace. In my previous experience with other systems, if you just look open a part or assembly, the system would serve you the most up-to-date revision by default. If you wanted to make changes, then you'd create a workspace and check-out your parts/assembli/drawings, make your changes and go through the approval/revision process if necessary before checking them back in.
In Onshape, the scenario is reversed. The default view is the open workspace, where you don't have clear visibility to status or revision of parts, and you just mark specific model states as "released". It doesn't feel like there's a controlled environment that you can selectively push changes into.
So, here's a thought experiment - what if we could delete the "Main" workspace (but keep the branch) and all edits would need to be done within other branches before being released back into the main branch? I'm not sure how you would handle the release of a single part created in a multi-part part studio. Perhaps you treat it like a derived part behind the scenes so that you can show only the parts that are released. This doesn't really solve all of the release workflow issues, but at least this way there is a clear place to go in order to see all of the most recent released parts in the document.
Tim, I haven't thought through all the scenarios or had time to test but definitely, think this has merit and feels like what I want to see. I really want a clear, reliable uneditable version of the document that shows all the latest releases. I was thinking that the unedited main sorts of gives this if you never make any edits in it and only edit on the branches then merge and release but this is not true, as changes can come across from the branch so I never have confidence now that the main is the latest. I'd be really keen to see a solution to this.
Twitter: @onshapetricks & @babart1977
HWM-Water Ltd
HWM-Water Ltd
That would also probably make it easier to share things with outside users (suppliers, manufacturing, etc.) without having to create "cleaned" documents to hide in-progress or unrelated data.
Default Workspace when Opening a Document:
- Main Workspace
- Latest Version (Read Only)
- Latest Revision (Read Only)
In the future this setting could be implemented at the Project Level or even the Team Level.Another great Option would be to Hide Main Workspace when sharing View Only.
CAD Engineering Manager
Also a release only branch is tricky. Imaging you have a part studio with three parts and each part was released in a different version. Now it would be very tricky to have a view for the part studio that pulls these potentially different parts from different versions into the same workspace.
However, I'm trying my hardest to use RM in my production work - and I really, really appreciate the fact that it keeps track automatically of revision levels. My main complaint (as some have already eloquently described) is that the Version and History Manager is cluttered with every single released item...I like the discussions centering around reducing that clutter for sure.
Keep it coming, and here's hoping OS has some improvements up their sleeves.
But, hey: happy Third Friday everyone! Maybe there will be something tonight!
Currently when a version is created or any change to one part within a studio all drawings show as out of date. Using part configurations now and like it a lot, however, all assemblies show as out of date even when a new part configuration is added. Versions must be used to see a new part added to a configuration. A month or 6 months down the line I don't necessarily remember what the change was and am obliged to go through all assemblies and find out if it matters and do I need to update.
Would like versioning to be allowed for individual parts.
Drawings and assemblies could then show out of date for pertinent changes only.
When inserting part configurations no need to see all as out of date just because a new config is added.
For the time being I'm currently working on my own and that will change and not using release management as I've been able to keep track and manually raise revisions but as others come on board it will be wanted and a more granular method would be good there as well.
Machine shop personnel want to quickly find drawings for parts and often also drawings for related parts (used on a common assembly). They do not often have the part number memorized, but do know the name and part number for the product (the top level assembly). They occasionally also require solid models, but always with an accompanying drawing. Warehouse and purchasing personnel similarly wish to access drawings of released parts and assemblies for quality control and for part identification/differentiation. They do know individual part numbers, but the search interface is slow when they have to manually filter each query so they usually resort to browsing.
In all cases, the context is usually groups of parts associated with an assembly, so they would prefer to browse exclusively by released assembly rather than by document. Links to all released drawings referencing said released assemblies would be listed in the assembly record. Navigating to an assembly would open a BOM view with records for each part containing links to the part studio and to all released drawings referencing each part. To save on clicks, if the links to the documents had a context menu with the option to export or print it would be ideal.
Further, the shop personnel prefer speed to detail when browsing, so a basic thumbnail and text BOM view with no document window (to eliminate loading lag) would be preferred. If the thumbnail view reduces performance, it would be better to have a text only list.
A wireframe of what I imagine - top level:
Drilling down into an assembly:
This is similar to the GitFlow version management approach that Onshape recommended before they added Release Management. I think that it provides a preferable structure to the current Release Management implementation for many use cases (my company included).
https://learn.onshape.com/learn/article/gitflow-version-management
As others have noted, the approach could be greatly improved if OnShape added a release workflow for merges and adding a lock to the 'main' branch, only allowing edits during the release process.
Twitter: @onshapetricks & @babart1977
A locked branch (nominally MAIN or the primary trunk) would have the workspace hidden by default and contain only versions, perhaps named something useful like "RELEASE 1.00 - 1 JAN 2019".
Default browsing and search result behavior for all users would be to open the latest version (release) from the MAIN trunk. This makes it easier for infrequent users to find production ready released documents and they would have to go out of their way to navigate to unreleased versions or to workspaces.
Versions (releases) as always could be branched to create new workspaces for edits. When a change is ready for release, the user creates a version in the edited branch and flags it as a release candidate. After the requisite approvals (skipped if the approval option isn't checked in company preferences) the release candidate may be merged into MAIN. Because merging sometimes requires extra work (changing callouts on drawings, updating assemblies, etc) MAIN would temporarily contain a workspace named something like "WORKING CANDIDATE 1.01" and (if the preference is set) drawings would be watermarked "RELEASE CANDIDATE" until the changes were finalized (second approval process?) and MAIN would have a new version created, "RELEASE 1.01 - 15 JAN 2019", and the workspace would be removed. The state of all tabs in the latest release would be changed to RELEASED, and the state of all tabs in all other versions would be changed to OBSOLETE.
In this process any changes to tabs would be tracked with a minor revision increment (ex. A.01 > A.02 > A.03) until the final release, when it would advance to the next major increment (A.03 > B ). The major revisions would conform to company standards, the minor revision trackers are merely to indicate that something had changed inside the release candidate and could be stored in a separate tab property. This avoids hundreds of unreleased revisions while still tracking incremental changes between releases.
Software guys have been working with versions and branching for a long time and have worked out most of the difficulties to the process in the context of sofware development. The hard part to adapt to a manufacturing/mechanical design context is change management beyond the CAD system - the guys on the shop floor get royally p*ssed after the 3rd or 4th revision with nothing new (released because another part from the same part studio was modified), but a software dev wouldn't really care if you made 100 new versions of a file with nothing changed but the timestamp, provided the code still compiles and passes their automated unit tests. This means that we have to be more deliberate with our releases than a software team would.
The above thoughts are just a brain-dump and definitely would be subject to modification under the harsh glare of reality and the needs of different contexts in other organizations.