To any Pro users not using Release Management...

owen_sparks

Hi Folks.

Just a gentle nudge.  If you happen to be a pro user and you're not currently using the included "release management" tools then I heartily recommend you give them a look.

I'd let them slide past me (a bit like labels when they were introduced) but saw PT demo them as an incidental part of a webinar as am impressed. 

In a nutshell Documents have Versions, Parts have Revisions. (Could we please have words that sound a little more different to each other next time please!) Say "Version-Revision" 10 times and then let me know which is which...

Use part revisions in place of document versions and no more annoying update icons for all the parts that haven't changed in all your assemblies when you add a single new part to your "common parts library document".

I've been bleating about this for ages and the solution was right there. 

There are other good things too, but worth it for this alone IMHO.

Cheers,

Owen S.

john_mcclary

Yea, yea, I really mean to look into it... but it's sorta intimidating.
Really it's about just biting the bullet and actually take the time to dig into it.

I saw the benefit of an rev system that has been set up in the video. Looks simple in the video, but seems like there are a lot of options that can be setup.

Our company is always on Rev A.

We walk out to the shop and throw away all the old copies and then hand them a new print.

It's a pain in the arse, tedious, and time consuming. But we design one-off / prototype style machines.
Typically our changes are minor (material/paint/stocksize callout/quantity) you know the small stuff that will really bite you later on

So I would like to have it set up, but it kinda feels like I'm gonna strong arm them into using something they don't really want. I'm already strong arming them into using Onshape for some projects. And I hear the crying and kicking and screaming when it's slightly different then what they are familiar with.
(thumb sucking cowards... anyway)
Because our company is not used to a Rev mentality. I really don't know where to begin on setting one up.

owen_sparks

@john_mcclary I had to read that twice to see if you were joking or not.

We're a small-ish company but to have any customers in the UK we must have ISO9001 accreditation, and that means we must have strict procedures.  Even if we didn't I'd gladly use revision control voluntarily just to avoid screw some ups and then the blame game that can ensue.

Resistance to changing from all Rev A documents to revisions sounds like having resistance to removing a blindfold whilst driving down a highway.  Just do it already, they'll thank you in the end.

Owen S.

michael_bromley

I've been using it for a while now and quite honestly struggle with it. Here is how I see it:

The positives:
1. You can capture a review/release process
2. Document the release state and revision of part/assembly/drawing

The negatives:
1. Rejecting/discarding gets very old when there is feedback.  Having to recompile/submit the release package each time can be painful.  In addition the comment feature is nice, but it does not carry forward.  If feedback was left the reviewer must know to go back to the previous release to review it and ensure it was incorporated.
2. Release states do not carry through document versions - meaning it is difficult for a user to understand the current status of the objects in a document
3. View the revision history from the instance tree, but no indication of the current rev level that is shown in the assembly.  I know that the BOM can be used for this, but I have to reconfigure it each time to show all the right columns.

Do you go through and update your assemblies to show all released parts (triangle icon indication) after the release of an assembly?  I find that without doing this, unless the assembly and all parts were released in a single release it gets confusing quick. 

Overall it is a step in the right direction, but I believe that it still needs some work to make it easier to use.

Doug_Jones

Nice to see these discussions pop up on release management, and that Katie is working on training assets.  We are just starting to think more deeply about this, as there is pressure to nail down change management.

We are coming around to the principle that Onshape document versions will need to correspond with Item/PLM release states, if we want to stay organized and consistent.  By item release states, I'm referring to traditional PLM/ERP states such as "Approved for Prototype", "Released for Tooling", "Production", etc. This simplifies the issue of needing to track a common release state across individual objects in a document, of which there may be many (top level dwgs, assemblies, spec sheets, etc.), and allows you to use simple, independent revision schemes for the associated objects.

Still thinking through this though. 

tim_hess427

@Doug_Jones - when you say "Onshape document versions will need to correspond with Item/PLM release states" are you referring to the version history and tree? Does that mean you'll only create a new "version" when moving to the next stage, such as "Approved for Prototype"?  What if you need to make and test a couple different versions of a prototype?

 I've been playing around with a custom property to correspond with the design and development stage. This way I can label a part as "production" or "prototype" in its properties, and can even display this on drawings. My thinking is that I may go through several revisions on prototype parts as I build and test (REV A through C), but then when I'm ready for production (maybe REV D) I can update the property as such. 

I'm sure my thinking has some holes in it, but I like reading on here and seeing what others are doing. 

Doug_Jones

@tim_hess427

Yes, so any build events would also be versioned, in addition to the lifecycle/release states. So if you are doing iterative prototype builds, you might have a document version sequence like:

Concept Approval

Release for Prototype

Prototype Build #1

Prototype Build #2

Prototype Build #3

Release for Quote

Release for Quote (Revised)

Release for Tooling

PPAP

Certification

Release for Production

Or if the prototypes are not iterative and you are looking at competing design variants/options (optional materials, construction, etc.), you'd use the branching. That's the thinking anyway.

tim_hess427

@Doug_Jones

Ok, that's about how I'm planning to do things as well. The exception being I'll probably document the things you've listed as Revisions so that we can use the approval flow, and just another level of hierarchy in the history. 

I think I'll keep the custom "prototype" property, or something like it just in case somebody has an old version of a drawing, they'll still know it was a prototype drawing and not any type of production release.

raj_Onshape

tim_hess427 said:

@Doug_Jones

Ok, that's about how I'm planning to do things as well. The exception being I'll probably document the things you've listed as Revisions so that we can use the approval flow, and just another level of hierarchy in the history. 

I think I'll keep the custom "prototype" property, or something like it just in case somebody has an old version of a drawing, they'll still know it was a prototype drawing and not any type of production release.

If you use Onshape release management you can use the setting Show watermark for unreleased drawings to ensure that only drawings that are released are watermark free. Obsoleted older version drawings and inprogress work within a workspace always have watermark to indicate what state they are in

tim_hess427

raj_Onshape said:

tim_hess427 said:

@Doug_Jones

Ok, that's about how I'm planning to do things as well. The exception being I'll probably document the things you've listed as Revisions so that we can use the approval flow, and just another level of hierarchy in the history. 

I think I'll keep the custom "prototype" property, or something like it just in case somebody has an old version of a drawing, they'll still know it was a prototype drawing and not any type of production release.

If you use Onshape release management you can use the setting Show watermark for unreleased drawings to ensure that only drawings that are released are watermark free. Obsoleted older version drawings and inprogress work within a workspace always have watermark to indicate what state they are in

Thanks for the tip. I do have that feature turned on. However, there are two things I'm trying to situations I'm trying to accommodate:

1. The situation where we release a prototype revision. We want to go through the release process so that we've got clear documentation about what parts are being prototyped and tested. In this case, we still want some sort of indication that the part depicted on the drawing is still a prototype (regardless of whether you understand our revision scheme). Maybe an alternative in the future could be watermarks that are tied to specific revision levels or custom properties?
2. Its my understanding that the watermark indicates the status of the DRAWING and not necessarily the PART(s) referenced on the drawing. I've been updating our title blocks to clearly indicate the status of the drawing as well as the part. 

I'm not sure if this the best way to be doing things, but I wanted to explain my current thinking a little bit. 

brucebartlett

@Doug_Jones @tim_hess427

What I've done is use a custom revision list. This way I can first layout my prototypes as numbers1-30,  * as my first release, then standard revs ABC... after that. It seems to work OK. You just have to manually type * in the rev field when you do your first release to bypass the numbers after that keeps incrementing in your laid out order. 

Stefan_DMS

On the topic of releasing part vs releasing drawings, I don't really know how that works.
Sometimes you release a part without the drawing, then go back and do a drawing, release the drawing, and then the part needs a re-release. That may happen with a missing dimension on the drawing, no change to the part but a re-release is required. 

We also want our drawings revisions to always match the part revision. 

john_mcclary

So I set it up to mess with it, cause I like the fact you can version individual parts in a part studio and update certain parts in the assembly to increase regen performance.

But then an email popped up and notified me that my part has been released...
Nnnnooope! I can hear the bitching from full inboxes already. I already had to exclude a couple of people from a team because they didn't want the spam when I share my projects on release.

That and we kinda do the guess and check method of design   draw a rough shape, stick it in the assembly, tweak 10 times. (we call in massaging ) that would be about 100 emails a day to keep checking the part fits.
So the workflow @philip_thomas showed in the webinar probably wont work for us. I'll stick to versioning method instead

That and it sucks I'm forced to create a part number up front (I don't know part numbers until I actually start putting parts to paper) and a release name (which even in the webinar philip just hits a bunch of random letters just like I would) so it's pretty much a useless requirement if it is just ignored anyways. Why can't that just default to "r1" or something like versions do "v1".

Anyways,
So, now I can't really say I didn't try it, but it just doesn't fit with our small company. Probably be good if we have repeat work I suppose, or parts that get used between jobs. Oh well.

MBartlett21

@john_mcclary
Can they change their notification options?

john_mcclary

I suppose so... haven't looked at that option in a while.
But what I'm getting at, there should probably be a notify checkbox each release, then it would know not to send to people who actually do like to be notified about things (when relevant)

philip_thomas

Lots of good discussion and as always, this is how you help us make the product better. 
Yes, Katie will be covering these workflows (i love the solution to the rejected ECO that you will see).
@KatieHuffman - perhaps also to include how to sync up drawing rev with part rev (totally doable) and the logic behind the custom release scheme (absolutely possible to jump forward through lifecycle changes as Bruce showed).

Katie, is there a list yet that anyone can sign up on?

KatieHuffman

The EVP course is running this afternoon, it is full. However, you be will be able to sign up for the December and January offerings by the end of the week!

3dcad

Uh.. Why can't I just create versions per part / per assembly / per drawing and manually set if it's currently in progress or finished (or other custom states).

I feel all this revisioning being too much of hassle for the simple stuff that we do - but I still would like to have control over what model/drawings we used for prototypes, what changes have been made since and what is the current state of part/assembly/drawing.

I'll probably end up duplicating tabs and naming them as versions storing into tab folders rather than creating some forced revision path for myself.

Stefan_DMS

@3dcad
You can do that, just change your company revision setting to Manual, rather than the Onshape workflow. 
Then in you versioned part properties, you can manually set the part as pending, released, obsolete ETC.

Or if you want to use your own list, you can create a custom part property list for parts, and create your own scheme for the revision path. 

I would recommend sticking with the Onshape workflow, as new changes will be built on the current workflow, and will eventually be fully customisable which will be very cool. 

Something to think about is versions are for document-wide version. revisions are just a special version that specifies a specific part/drawing/assembly revision number. And the revision has a pending, release, obsolete path embedded in the metadata. 
When using assemblies and you only use released parts, when you version a document you don't get all the blue icons (to update the parts) until you release the new revision of that specific part.

Cris_Bowers

I'm the only Onshaper in my company at this time. We have another license that isn't being used that was for my boss so we could actually use release management, but he spends about 50% of his day in meetings, the rest of the time he's working in Sketchup or AutoCAD. They've actually never had a review and release process in place here. We design our products, then make our drawings, and then send them to the shop floor. If changes are made in the shop we likely won't find out for five years when they get tired of remembering to make the modifications they never documented for us.

KatieHuffman

If you are interested, the Release Management course is available and ready for students. It is one 2-hour session. Please email training@onshape.com with any questions.

3dcad

Stefan_DMS said:

 
When using assemblies and you only use released parts, when you version a document you don't get all the blue icons (to update the parts) until you release the new revision of that specific part.

I create assemblies in very early stage to get the looks and model for render, then finish models only if we get the deal and proceed to production. All products are a mix of standard, copied from existing templates and new parts. Models can have some temporary parts only for render. Single document holds multiple products (a collection) since they share similar design and usually some parts.

In the end we have roughly a dozen assemblies using same parts per product (complete product, assembly steps, packing instr. etc..)

I might be wrong but I suspect if we can follow any 'standard release path'.. At the moment I only create versions when forced by Onshape to being able to use linked docs. So we are working in 'Main' and everything updates instantly - and that's exactly how I like it. But I would like to 'mark' certain milestones (per part / assy / drawing sheet) to being able to go back / investigate changes if needed. And show state of current work so no one will use unfinished data.

I will give RM a shot at some point, but I wan't to keep things agile and see the changes instantly in assembly when part is updated. I wouldn't mind if Onshape kept track of part version behind the scene and let me set assembly to use always use newest version/revision (like v1.1.3.12) but would let me try how it was with v1.1.2.9 if needed. So I don't wan't to concentrate on (learning) Release Management, just wan't software to keep track of changes per part / assy / drw sheet etc.

philip_thomas

@3dcad - Rami, when you have had a chance to play with it, I would like to set up a meeting with you and Lou and possibly other members of the UX team to collect your feedback and to make sure that we are supporting these workflows. Send me an email when you're ready

3dcad

@philip_thomas

Sure thing!

sebastian_glanzner

@owen_sparks
Thank you very much for creating this topic! I activated the release management workflow last week and it is really useful!

I think the option "Show watermark for unreleased drawings" under company settings is quite important for everyone. But how do you save a pdf without the watermark? At the moment I can only download a pdf, but can't save it in the revision.

I think the creation of pdfs should be automated by Onshape when a revision is released. This is also important if you set an old revision to obsolete.

brucebartlett

@sebastian_glanzner if you release a drawing the watermark will disappear on the version, you will need to find the version by navigating using the version graph to where the drawing was released and here it will live without their without the watermark. 

sebastian_glanzner

@brucebartlett Yes you are right, if click on the version you find the Onshape drawing without the watermark. But I can't create a pdf of the drawing (without the watermark) and store it in the version, because versions are view only. 

3dcad

@sebastian_glanzner
Why do you wan't to have pdf in Onshape? Drawings inside a version is already in 'portable format' and can export any time - no need to worry about being changed. Or do you need this for quicker access? I think Onshape wants to solve speed issues from different approach than auto-creating pdfs..

I think the idea of auto-pdf would be useful, I'm just trying to figure why it's not already there since it shouldn't be a big revolution in coding perspective.

sebastian_glanzner

@3dcad I'm working with several customers. Two of them have the habit to save every Revision of a drawing as a pdf and every part/assembly as step-file. At the moment they haven't switch to Onshape, but I can already hear them ask: Where are the release pdfs and step files?   

Maybe I'm also stuck in the past and I should get rid of the pdf and step-files altogether   
But then I need a better sharing solution for vendors, so I can share only specific parts and drawings.

john_mcclary

We also Step/PDF everything per release. I just don't re-upload to Onshape. We have a job folder on our network for that, then we email the pdf/dwg/step to customers/vendors as necessary.

No need to re-upload them because if you give them an Onshape link, just link them to the version of the drawing. They can print just as easy from there as a pdf anyway. Step / DWG will be a little more of a training session, but not totally out of the question.

You could almost trick them into believing the Drawing tab IS a pdf

philip_thomas

@sebastian_glanzner:

Horrible UX fail on our part! Sorry.
The 'download' button is grayed out because it cannot be changed. The ONLY option is download.
You will see that the Export button is good to go and yes, that is the way to make PDF's of released drawings.
We will remove the 'gray'. No functional change (because it works )