Hardware versioning is a topic of its own. In short, I suggest that the hardware version be separate from the software version.
Hardware version is typically made up of a few things:
- product: several products could be built out of the same firmware code base, e.g. at Pebble every watch different builds of the same firmware
- board configuration: you might have slight differences in configuration. Another typical thing here is to encode the proto build (e.g. EVT, DVT, … etc…)
- revision: an incrementing integer is fine here.
You can then compile different firmwares for your different hardware versions, or you can have a firmware that detects and adapts to the hardware version it is installed on. Most likely, you’ll have a mix of both (a few different firmwares, each capable of running on a set of hardware versions).
So say we have 4 hardware versions:
- foo-evt-r1 → the EVT hw
- foo-dvt-r1 → the DVT hw
- foo-mp-r1 → the release / mass production hw
- foo-mp-r2 → a new revision of the MP hw
When you release your new firmware version (say version 3.2.1), you’ll generate the following binaries: foo-evt-r1-fw-v3.2.1.bin
, foo-dvt-r1-fw-v3.2.1.bin
, foo-mp-r1-fw-v3.2.1.bin
, and foo-mp-r2-fw-v3.2.1.bin
.
As you can see the hardware version and the firmware version are completely separate.