Posted By Alex Gammelgard, May 17, 2012 at 1:30 PM, in Category: The Innovation Enterprise
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.
Written by Alex Gammelgard