A fundamental requirement of good product development is revision management. Change is inevitable, but it should be managed. Properly.

Software developers have the luxury of powerful (and free) revision management tools like git. The choices aren’t as clear cut, nor efficient for hardware developers. Most hardware file revisioning workflows have some level of manual intervention – specifically on revision labeling.

Proper revision management labeling policies are critical and often under appreciated. The key is to remove ambiguity and subjectivity. There are several different revision management labeling styles in use in the industry today, many of which unfortunately don’t follow these guidelines.

What’s the risk?

Here’s the fundamental contributing risk in hardware product development: The team that designs a product is not the same team that manufacturers it. So, documentation should be clear and concise.

When a design team makes a change to a product, they are much closer to the problem being resolved, so understand the context of the change. The manufacturers do not. To them, a change is a change. It’s not their responsibility to know the criticality of the change. Their job is to implement the change and deliver the finished good to the quality specified.

So, when teams devise complicated revision labeling, it serves no purpose in the grand scheme of things, and only results in adding risk for mistakes and delays.

Don’t introduce uncertainty

Revision labels should be simple, single number or letter values. No decimals, sub-level values, or major – minor values. These multi-level revision labels only lead to confusion or a dependency on some complicated ruleset.

If your team follows a major.minor revision management scheme (e.g. Rev 2.4), how do you decide if a change constitutes a minor revision or major revision bump? Should the next revision be Rev 2.5 or Rev 3.0? Some changes will be obvious, but many will not. Why introduce uncertainty?

K.I.S.S.

The right solution is to keep it simple, and use only positive integers and single character letters. (Rev. 1,2,3,…, A,B,C…Z).

More explicitly, I promote the adoption of the following Revision labeling policy:

  • If the part/assembly is in a Prototype state, it has a positive integer revision label (1,2,3,…n).

  • If the part/assemble is in a Production state, it has a single character letter revision label (A,B,C,…Z).

  • Skip letters I,J,O,Q,S – these characters can too easily be misread and interpreted for numbers.

Why is this a good policy?

  1. There’s no ambiguity. Any changes that constitute a revision bump get the next logical value. There’s no thought or debate whether the change is a major or minor one.

  2. Suppliers often have different procedures and costs associated with prototype vs production runs. Using a clear differentiator in the revision label quickly routes the change to the right team and workflows, with no ambiguity or additional explanation required.

  3. It’s common to have many more revisions while prototyping vs in production, so using integers allows for infinite values.

  4. Production revisions are much fewer, so using single character letters doesn’t limit you, in practice. Note: If you get up to revision Z in production, then there is something seriously wrong with your QA processes!

A change is a change

The only valid argument I hear for having a major.minor revision labeling scheme (e.g. C1, C2, D1, D2, D3, …) is to identify relationships between revisions. In some cases this is necessary for compatibility or interoperability reasons. For example, one might say that any subassembly with revision Cx is interchangeable but revisions D or higher are not.

But I question whether this ruleset is worth the effort? One still has to document the compatibility rules, so why add the complexity? These rules are often only for internal use only – the supplier doesn’t care. A change is a change.