Release Management Questions

robert_morris

I've been looking through the help file on the new Release Management stuff and have a couple of questions.

1. In the help file for releasing assemblies it states: "Released parts linked from other documents, in the Assembly, are reflected in the Create Release candidate dialog and no new revisions of the parts are created when the Assembly is released".   What about parts that are within the same document?  If I create a new revision for an assembly that contains a part which has not changed from the same document, will the revision of that part be bumped up as well?
2. If a release candidate has been rejected, will the revision value (A, B, C..) get reused the next time a release candidate is created, or will it be bumped up to the next value.

Jason_S

@robert_morris

1. If you have a part that is referencing the workspace part and not the released part, the revision will be bumped when releasing the assembly. If you are releasing a part that is referencing the released part, then the revision will not be bumped.



2.The revision value only gets bumped when a release candidate is approved. Rejected release candidates appear as open triangles in the Versions and history graph.

Probably your next question:
If there are two pending release candidates that contain the same part with the same pending revision value, the first approved one wins and takes the new revision value. We will not automatically discard release candidates for you, nor will we make you take action on the pending one. Your pending release will show you that your part's pending revision value has already been taken and the only action is to either discard or reject.

robert_morris

@Jason_S
Thank you for the clarification.

Having the part revision automatically bumped when I bump an assembly revision is a big giant no-no for me. For example, adding a new part to an assembly and creating a new revision shouldn't bump the revision of the other parts since they haven't actually changed.

So it seems my two options to prevent this are:

1. Move all the parts into a separate document, release those, go back to the assembly document, update the links, and then release the assemblies from that document.
2. Keep the parts in the same document, release those. Then completely rebuild my assemblies and subassemblies to use the released parts (there doesn't seem to be a way to switch from a normal part to a released part like you can with versions), and release the assemblies after all that has been done.

Both options currently require a bunch of extra time taken, and the first option seems (to me at least) to lose a big benefit of having things all in one document. It would be nice if you could switch an unreleased part in an assembly to a released part. That would reduce the extra time taken for option 2.

I could also be missing something and there's an easier or more correct way of doing this.

Jason_S

@robert_morris
You got it mostly. Note that revisions are versions, and if you are currently referencing a version, you cannot change to the actual revision (yet). You would just be updating to the version that was created at the time of the approved release candidate. So you would still get version updates. Broken down:

 - If you are referencing a version, you can change to another version or workspace. 

 - If you are referencing a revision, you can change to another revision, a version, or a workspace. But today, if you hop off the revision train, you cannot get back on without reinserting the object. 

Right now Release management works best if:
1. Don’t mind bumping revisions often. They are free and even if there were metadata changes, the part has changed. If the part has changed, you probably want to re-release the assembly when all the other parts have been changed as well. 
Implementing revisions and the release process going forward is recommended.  
2. You have the patience to go through your assemblies that matter, release the parts and reinsert the parts. This is a very large ask and I don’t suggest this if you enjoy your weekends. 
3. Start using them on your next project.  
4. You are brand new to Onshape and you only know Onshape as it is today. 

In previous PDM systems, bumping revisions was a no-no because the process was laborous and required the design to stop just for everyone to get on the same page. This is just the beginning in Onshape’s mission to make this once tedious task something that just blends in, feels natural, and does not get in the way of what engineers like us love doing: Engineering and solving problems together. 

We know that the ‘change to revision’ work is work that needs to be done. As with the rest of Onshape, expect workflow improvements in the future. 

robert_morris

@Jason_S
Thanks again for the info. I have no doubt there will be improvements in the future, and we all appreciate that.

I don't say that automatically bumping revisions are a no-no for the reasons that you point out, although those can be true as well. I say they are a no-no because if a part revision is bumped up, then that is normally a signal to whoever is manufacturing the part that something is changed. If there is nothing actually changed in the part, then that wastes the manufacturers time (and ours) as they try to figure out what's different and why it isn't called out.

Bill_Martin

I have seen this now in one of my projects.  I agree, having to bump up a Revision with no actual changes is confusing at best.  In my case, I did an inial Rev A release of a set of drawings with four of the parts that need to be manufactured in a machine shop.  Other parts in the Document and Assembly are for 3D printing in-house.  When I went to do the initial Release of the 3D printed parts--the machined parts want to go to Rev B...for no reason.

michael_bromley

I agree that it does get a bit confusing as the state of release does not carry as it does in conventional CAD systems.  It is possible to change the version of each part to its released version in an assembly and then it will not automatically assign it the next revision.  I have tried this technique, but it gets very confusing as it marks each part as "linked" even if they are in the same document when you change it to a previous released state.  I'm still working on coming up with the best practices for using the release management system and would love ideas.  It seems error prone right now trying to figure out what has changed and what hasn't when doing multiple releases within a document.

jakeramsley

michael_bromley said:

I agree that it does get a bit confusing as the state of release does not carry as it does in conventional CAD systems.  It is possible to change the version of each part to its released version in an assembly and then it will not automatically assign it the next revision.  I have tried this technique, but it gets very confusing as it marks each part as "linked" even if they are in the same document when you change it to a previous released state.  I'm still working on coming up with the best practices for using the release management system and would love ideas.  It seems error prone right now trying to figure out what has changed and what hasn't when doing multiple releases within a document.

Hi michael_bromley,

We are working on improving versions, revision, linked documents and the general updating and notifications of it all.   Our system is a very different paradigm from file based parts with PDM tracking on the file itself.  From what I am gathering from this thread, there is difficulty in that there is no one-to-one (or one-to-many) link between actively being worked on parts/assemblies and their released equivalent leading to a grey area of whether to insert & reference the workspace or released part/assembly?

Can you clarify what you mean by "as the state of release does not carry as it does in conventional CAD systems."?  From my initial reading, I would disagree but I don't want to form an opinion based on a misunderstanding.

michael_bromley

Hey @jakeramsley,

  What I mean by the state not carrying is that as soon as a part has been marked as released in a version the current work space, main, shows that part in work again.  The confusion comes when there has been multiple different release packages releasing different parts.  It is difficult to determine what has been released previously, what still needs to be released, and if there have been any changes to a previously released part.  You could very easily release the same part twice as two different revisions without making any physical changes to that specific part because the overall document had undergone some changes.

For example, I release an entire assembly of parts and it is approved and that version is marked as released.  If someone else opens up the document and begins working in the main work space they would not know that assembly had been released without digging in and looking for it.  Our issue is that it is hard to get a high level view of the current status of all parts, assemblies, and drawings.

Hopefully that makes some sense, but I'm happy to talk through it more if it would help.

robert_morris

To clarify my issues. My problem is the fact that parts within an assembly that are in the same workspace are automatically revision bumped when the assembly is released even when there has been no changes made to them, and the only way around that (currently) is to rebuild the assemblies with only revisioned parts which takes bunch of extra time that I usually don't have.

brucebartlett

robert_morris said:

To clarify my issues. My problem is the fact that parts within an assembly that are in the same workspace are automatically revision bumped when the assembly is released even when there has been no changes made to them, and the only way around that (currently) is to rebuild the assemblies with only revisioned parts which takes bunch of extra time that I usually don't have.

This is a problem, a released part should stay static in an assembly unless changed.  Even without release management, we see this, where as soon as a linked document is versioned, every linked part now has a blue paperclip weather changed or not. 

brucebartlett

One other thing is it possible to have initial release set to a character other than A, ie. * or - . To me and companies I have worked for, A is for the first revision, not the initial release.  

Also, can we have a mix of letters and numbers,  I have seen some companies use numbers for pre-release revision/versions and letters for post initial release revisions. 

garrett_rayner

Jason_S said:

We know that the ‘change to revision’ work is work that needs to be done. As with the rest of Onshape, expect workflow improvements in the future. 

Thanks to all for working through this-- this thread has been super helpful for me as I try to implement release management. Wanted to throw in another question that this led me straight into:

If we've already committed to spending our weekends updating our assemblies with released parts, then in order to evaluate the impact of a part-level change on a released part in an assembly, it seems like my options are:

1. make the changes to the part in part studio, release a new revision of the part, and update to the most recent revision in the assembly
2. make the changes to the part in part studio, change the pointer in the assembly from the revision to a version, then update to the current (modified) version. Then, if change is OK, release part and re-insert released part into assembly (probably requiring some level of assembly rebuild)
3. make changes to the part in part studio, change the pointer in the assembly from the revision to a version, then update to the current (modified) version. Then, if change is OK, release part and change the pointer back to the new revision.

Option 1 would require a massive number of revisions, even for investigations, which seems like an abuse of the tool.
Option 2 would require assembly rebuild for any part change.
Option 3 seems great, but requires the 'change to revision' work that you reference above.

Do I have my head on straight re: my options here? If so, is option 1 or option 2 the current recommendation? And any insight into where in the pipeline option 3 is?

Jason_S

@garrett_rayner  You are asking all the right questions and seem to have grasped everything very well!

Going back over your list:
Option 1 is a lot of work, agreed. This will be much easier when we eventually have the ability to push/propagate revision updates to assemblies in some way.
Option 2 is pretty laborious. Personally, I wouldn't do this.
Option 3 you are totally correct this would be great. 

We implemented release management with the intention to cater to as many workflows as possible, with an increasing amount of workflows being supported every few weeks. I believe what is 'recommended' all depends on your release process internally. Your team probably already has an idea on how YOUR project should develop, and your CAD/PDM should be causing as little disruption to that process as possible.

If your team has a very locked down mentality, start (and keep) everything at revisions so there are approvals for everything.
If you don't mind extra revisions, you can keep your assemblies as is and rereleasing the parts or assembly however you see fit.

There is no one size fits all solution to product development. We know the change to revision workflow is very desirable functionality and we are working on it.

michael_bromley

I'm curious as to how everyone is handling building an assembly of released parts? (or just tracking the status of parts)  Typically I will design the parts and assembly at the same time.  However only a few parts may be released at one time in a version.  Unless I force my assembly to use the released version they will just remain at the most recent version.  It then gets confusing to designers that I collaborate with to determine which parts have been released, still in work, or released and have since been modified requiring another release.

Any thoughts on work flows to manage the release states?

Theo_R

@michael_bromley @brucebartlett

The conversations above have been helpful.

We are getting started with rev management and I am wondering if you can share your best practices / experience for OnShape document control. (In addition I see the issue of control models (rA) vs. drawings (rD) and do you keep them at the same letter?)
I recognize that a lot of this is dependent on the specific organization.

Thanks in advance for any insights.

EvanReese

I'm curious, has anyone used two assemblies for this? One could be linked to "Main" and update live with the part studio (this helps with ongoing development). The other assembly could be identical, but only linked to the latest rev of all parts. That's the one that would be used for drawings. This would mean that you'd have to do 2 releases each time: one to rev the parts, and another after that, to rev the drawings and assemblies. It feels roundabout, but seems to work well enough. It at least prevents releasing unchanged parts.

I'm definitely looking forward to more streamlining from the Onshape dev team here.

tim_hess427

Right now - we keep the drawing and model at the same rev level. So, our workflow is:

1. create/edit parts + assemblies until happy.
   
2. release parts and drawings together at same rev level.
3. update assembly to include only released parts. 
4. release assembly and assembly drawing at same rev level. 

This could be a little confusing to work on the assembly and make sure you've got the right part version in your assembly in your workspace. But after releasing the parts, you can update the assembly and review that everything is still correct before releasing it. 

@Evan_Reese - in your example - do you actually release two different assemblies? Or does one assembly just allow you to release the parts and not the top-level assembly? 

EvanReese

tim_hess427 said:

@Evan_Reese - in your example - do you actually release two different assemblies? Or does one assembly just allow you to release the parts and not the top-level assembly? 

I've not actually tried it like my example yet, but one assembly would essentially be a dummy assembly just to review changes in real time, and it would never be actually released. Otherwise the workflow would be as you describe above, with a different revision-controlled assembly meant for released parts only.

tim_hess427

Gotcha. That's essentially what I've ended up doing when making substantial revisions to a couple of assemblies. The trouble is that if the dummy assembly is in a separate document from the parts, then you might end up making tons of versions just to be able to update the assembly. Luckily, a lot of my changes were focused on parts in one part studio, so I could build an assembly in the same document to see most changes right away.