So, in response to the blog post from yesterday, here are two rules that could guide how component revisions impact assembly-level revisions. This is a tricky call to make because if you always let minor changes to low-level parts trigger new revisions  to your top-level product assemblies (and all the intervening  sub-assemblies), you end up burying yourself in documentation updates, but if you go too far the other way, you won't be able to distinguish which products contain the revised component and which don’t.

So - - - here we go. Here are two rules.

Rule #1: If the change represents a minor revision to the component, do not release a new revision of the parent assembly.

Rule #2: If the change represents a major revision to  the component, decide whether it also represents a major revision to the  parent assembly. If it does, release a new major revision of the  parent. If it doesn’t, release a new minor revision of the parent.

The assemblies that contain a component directly are usually  subassemblies with their own parents. If this is the case, apply the  above rules to the subassemblies and repeat as necessary, all the way up  the tree.

Agree, disagree, or have another methodology for this all together?

And for a more in-depth explanation of this topic, here is an expanded discussion of this topic on the Arena Blog.