Semantic Versioning for Hardware Design
Share
With the pace of development in the software industry in terms of just managing complexity alone, there is a lot that the world of atoms can learn from the world of bits. At UMI we use SemVer for not only our software, but our hardware designs too. This gives us a uniform method for communicating the importance and effects of design changes with a simple three digit number.
If you haven't been introduced to Semantic Versioning yet, it's petty simple: the three digits are major, minor and patch. The major number is incremented to denote changes that break compatibility with previous designs. The minor number is used to denote changes that don't break compatibility but might add new features or capabilities. And finally the patch number to denote backward compatible fixes or performance improvements.
What this looks like at UMI is that each design start with the version number v0.1.0 and before each release of the design the version number is updated in accordance with the rules of SemVer. Because we use Git for our version control we tag each release commit with the version number so they are easy to find later.
Most of what we see in the industry is ether a single number counting up (i.e. R1, R2, R3) with each new revision or a custom versioning system that isn't understood outside that specific company.
Both of these systems work, but can be improved upon with semantic versioning and we'd like to see more adoption across the industry, especially with the growth of the open-source hardware movement.
Back-porting
With SemVer new changes can be added to old designs without requiring a new part number. This is typical when a customer or user wants something new without breaking their existing setup.