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.
Options
Diff check for released parts
michael_zeagler204
Member Posts: 8 ✭✭
When going through the release process I was wondering if this would be useful or implementable. I have some parts designed in context. If I want to release those parts and update that assembly to include them, and then update that assembly in a way that would change the context and those parts, those changes wouldn't propagate on their own. I'd have to replace them with the workspace version, release them, then replace the assembly's version with the released version, then release the assembly.
I've spoken with the support staff, and they ran me through some instances where I could minimize this problem with deriving studios from multiple bodies in their assembled orientation so long as they're static. That's sure to eliminate the problem where it's feasible. But I can still see a lot of cases where implementing some kind of check on parts when releasing them would be very useful. I assume it could be accomplished either by checking the final geometry or features for changes, or by checking the elements that generate them.
In this case revisioning would only occur in an assembly upon that assembly and the parts that had changed between releases. The release of an assembly and parts which are all contained within the document could be robust and self-enforcing, without the risk of revisioning a part that was identical, and without the overhead of multiple releases, or single use assemblies crowding a part studio with contexts. It might even be able to detect unintentional changes in simpler part studios.
I'm not sure how big a change it would be, but I thought it was worth shooting to the forum. It seems like so much of the process is already plumbed to some kind of analysis, so it seemed worth asking.
I've spoken with the support staff, and they ran me through some instances where I could minimize this problem with deriving studios from multiple bodies in their assembled orientation so long as they're static. That's sure to eliminate the problem where it's feasible. But I can still see a lot of cases where implementing some kind of check on parts when releasing them would be very useful. I assume it could be accomplished either by checking the final geometry or features for changes, or by checking the elements that generate them.
In this case revisioning would only occur in an assembly upon that assembly and the parts that had changed between releases. The release of an assembly and parts which are all contained within the document could be robust and self-enforcing, without the risk of revisioning a part that was identical, and without the overhead of multiple releases, or single use assemblies crowding a part studio with contexts. It might even be able to detect unintentional changes in simpler part studios.
I'm not sure how big a change it would be, but I thought it was worth shooting to the forum. It seems like so much of the process is already plumbed to some kind of analysis, so it seemed worth asking.
0