Build Numbers synchronicity when delivering on multiple OS platforms.

Question

My organization builds a C++ application that runs on multiple operating systems.

Should the build number, visible to customer, be the same for a given state of the source code tree on all the platforms?

Answer 1

There aren't any downsides that I can see. You want to be able to reproduce the build, so each should say what the build is. If it's the same build, it should be the same build number.

Answer 2

Yes, I think so.

One practice you can use is to use the changelist number or however your source control system identifies the checkin that your build system pulled to build your product. That way you always know what source you should pull to rebuild it as well.

Answer 3

If you choose to (or cannot - from a build process point of view) not use the exact same versionnumber for builds made for different platforms, you should document exactly what your versionnumbers actually imply.

If you don't, typically a user of the software will treat the whole thing (e.g. 3.1.0.333 - where 333 would be the build number) as identifying a certain version of the software (thuse the code tree). If they use your software on differnt platforms, they then might think that 3.1.0.333 and 3.1.0.334 are actually refering differnt versions (as in code changes) of the product, which they might not.

The same is true for outher "build number" styles, like using some sort of date/time derived build-id.

If you globally manage your build numbers, you might consider adding a platform ID. So that you can build 3.1.0.333-x86 and 3.1.0.333-amd64 one after the other, but still have them share the same "number". It will also be more obvious to the user what the indent/meaning is.