Revision versions are funny things. Revisions may exist in your engineered drawings, tracking incremental improvements, and enhancements. They may also be a method to acknowledge obsolescence. Revisions may also track versions of apps as they get pushed into production with every improvement or bug that is fixed. These may indicate major revisions such as significant overalls or down to minor revisions that correct grammatical errors. Regardless, of the version or revision of the product or document, knowing what version you have in your hand could be critical for an organization's success. So what should be our process to appropriately “mark” or “brand” this reference point?
I remember years ago an order was placed to a local fabrication shop for a spare. The order indicated that we wanted to have the part fabricated referencing drawings from the first revision. The drawing referenced for the fabrication had 1.0 in the bottom right-hand corner next to the drawing number. Unintentionally, the spare produced was made to the second version. We had indicated that we wanted the first revision, but we had sent 1.0. Is 1.0 the first revision? Or is 1.1? Then what is 2.0? What if we started with 0.0, then 1.0 could be the first revision. Right? What just happened! If we cannot figure out what came first, how can we run an organization?
Google “version controls” and you might have your mind blown about the number of people that will interpret that versions start at 0 or 1. The first iPhone wasn’t "iPhone 0" but a bridge put into commission over a body of water references engineering drawings showing rev0. Others argue that we are talking about Industry 4.0, and others will respond with what was Industry 0.0? Are those organizations that use "rev.A" doing it right, because nothing comes before the letter A? How can something that seems so simple create so much chaos?
At its most simple, a version control system, or VCS, looks at a file (or, more commonly, a group of files) and tracks changes over time. Each “snapshot” is stored as a version, and anyone involved in the project can make a new version. - Courtney Menikheim, GEO JOBE
This confusion around version control can cost millions if not, billions of dollars in damages to an organization or its reputation. A communication error on revisions and version history can happen very quickly and can be quite devastating when it occurs. In my opinion, the methodology of denoting the version history makes no difference. It doesn’t matter what you call it, sequence it, or the magnitude of sequenced Roman or Greek characters you use to denote a drawing, a version, and a revision.
Some might argue that there are some examples of programs that reference a 1.0 as the same thing as a 1.1. But, these are one-off examples of code looking at the globe’s variability and making an assumption. The objective here is that you are consistent and repeatable, and you communicate to your customers and suppliers what your format is.
If you are an organization that is all over the place in formats for version control, some formats can be used as good starting guidelines. One option can be the Semantic Versioning (SemVer) format of MAJOR.MINOR.PATCH. This approach is used frequently in programming and app development. Pull out your iPhone, and correlate this with how you receive your iOS updates. It is a fairly consistent elementary approach and there are plenty of examples to reference to build your standardization string. Using this approach with examples of your organization’s MAJOR, MINOR, and PATCH may allow you to create a standard format fairly quickly.
In the world of software management, there exists a dreaded place called “dependency hell.” The bigger your system grows and the more packages you integrate into your software, the more likely you are to find yourself, one day, in this pit of despair. SEMVER.org
There are people and organizations all over the world that have been doing it “this way” for years and consider that their format is the best. If you are a supporter of the National CAD Standard, you are promoting a discipline designator, a sheet type, and a sequence number. If you despise the National CAD Standard, you may be a proponent of others such as the British standards BS1192:2007+A2:2016 and PAS 1192-2:2013. There are formats everywhere. Each one is just a little bit different.
I don’t believe there will ever be a standard on this because the standard approach isn’t being sold nor can it be sold. Instead, it is strictly a reference point. This isn’t the Phoebus Cartel, with organizations such as PAS getting together with Semantic Versioning and US National CAD standard looking to standardize globally to improve sales. This isn’t a format that differentiates you from your competition. These are groups of people that are indicating that their way is the best.
Clients may insist on implementing their own document numbering system, or participating organizations may combine to create a new system. Regardless of the approach, it’s important to select a single method and ensure all parties are clear on the usage of the same system. Steve Kelly, Oracle
The next time you write rev0 on a document that you are writing or place 1.0 on the bottom left of a drawing number, stop and reflect. You are most likely contributing to the trap of variability within yourself, your employer, and the organizations that you engage with. The lesson learned here is that organizations should find a strategy, communicate the strategy, and ensure that it is being followed. If organizations fail at doing this on their versioning infrastructure of engineering drawing numbers, apps, and controlled documents, progress won’t be made. You will stay at version 1.0.