I’m really interested in learning about the different ways that people in the KiCad community version their hardware projects.
For example, in the software world, there are some widely adopted standards such as Semantic Versioning that assign a well-defined meaning to the
MAJOR.MINOR.PATCH versioning scheme.
I’ve seen many KiCad projects use versions that look like semver (e.g.
v1.0), but I’ve found that the meaning of the
PATCH version components can have very different meanings depending on who the project authors are.
Alternatively, some projects use a simple revision scheme (
Rev C, etc). Others use a simple version scheme (
v3). Others use a combination of version and revision (
V1 Rev A,
V1 Rev B,
V2 Rev A, etc). I’ve even seen some projects that rely solely on a git hash as the revision identifier.
If you have a versioning scheme that you’ve been using successfully, I’d love to hear about it. Specifically, I’m interested in understanding the meaning behind the version identifiers, and the logic that dictates when you increment the version. For example, if you use a semver versioning scheme like
v1.2, what does the
1 vs. the
2 mean to you? What would cause the version to increment from
v1.3? If the terms “version” and “revision” mean different things to you, how are they used differently in your workflow?
In particular, I’d really like to hear from folks who:
- Use Git for version control of KiCad files and release their design & manufacturing files (gerbers, PDFs, etc) through a structured release mechanism like GitHub Releases.
- Use KiCad together with a traditional product lifecycle management (PLM) system (Arena, Aligni, etc) that requires “part numbers” and “revisions” be assigned to all documents like the schematic, PCB layout, BOM, etc.
- Use KiCad for designing products with multiple iteration cycles, where multiple versions of the design need to be managed simultaneously (e.g.
V1is in mass production, while
V2is in the EVT phase).
Some context about where this question is coming from:
I’ve spent a lot of time designing hardware in [big company] where the PLM system’s Part Number + Revision is the source of truth. Every schematic is assigned a “drawing number” (part number) with an incrementing “drawing revision”, and each new revision of the schematic drawing is checked into the master PLM system. The PCB layout is also assigned a totally separate “drawing number” (part number) + drawing revision that does not match the ones in the schematic (changes can be made to either independently).
However, in most KiCad projects I’ve seen in the wild, the schematic & PCB layout (and sometimes docs & firmware) are all checked into a single git repo and releases of the entire repo are assigned a single version number like
I’m trying to reconcile my oldschool “big company” PLM-based worldview with a more modern software-like approach to project versioning (like semver), and I’m wondering if anybody has found an elegant way to bridge the two worlds together.