Release versioning might seem like a boring topic. Honestly, it should be. There should only be a couple of right ways to do versioning, and each project should pick one of the agreed-upon methods (SemVer, CalVer, etc.) that makes the most sense to the project. We don’t live in this ideal world unfortunately and many projects choose to deviate from versioning standards. I’m not here to say they are wrong, but I’d like to discuss what they might be missing out on.
So this is something I’ve been keen on, I stop personal projects for months then pick them up again… trying to work out which version of code i’m working on and which version of code my MCU is running is a challenge…my question is, have you found a way to automate this process ? Something in the workflow that prompts you for versioning information, that forces you to enter it or perhaps auto increments based on lines of code changed ? I’m a self taught coder and always forget to do this
Another important role for versioning in embedded devices: when attaching your debugger to running firmware, you really want to be sure you’re working from the same sources that generated the firmware.
How would you manage hardware change with your release versionning strategies?
For example, for manufacturing reasons, you change your GNSS IC on your board. While your application didn’t change, the new driver won’t be retro-compatible.
Is this a MAJOR or MINOR change?
What if you need to support both products?
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.