I think our model of the variations/version was different. So this is a very interesting use case if you go with GitBuilding
In OpenFlexure the core microscope was in a single repo (other repos for software/electronics, etc). Our variations were things like higher or lower cost optics. As such, the entire project moved to the new version and we ran the docs.
For this it seems that you have versions for each sub components, and then you build a specific machine. Using submodules is one way to make sure the modular git repository is correct. If all instruction files for the sub-assemblies are in these it should be possible to make consistent documentation.
However you need more than just assembly documentation. You might need upgrade documentation and you will certainly need user documentation. It would be interesting to think about this.
I think the hardest part of the puzzle will be to think about how to mark which versions are compatible. And also to make sure that it is simple to configure the submodules in an instrument by instrument basis. Git Submodule is pretty confusing, and someone needs to fork the repository and adjust all the submodule versions for their instrument. This seems quite messy and fork-heavy approach. I shouldn’t need to fork and edit a git repo to create documentation for a configuration. I should be able to clone the git repository, feed it in a configuration file and get the instructions.
Sounds like we need a hardware version of a package manager. This isn’t a new thing I don’t know if any of the toolchain research has looked into Configuration Management as I think it is called in the PLM world.
[Edit to say: I am not 100% sure I totally understand the term Configuration Management, some reading seems to imply that it is more similar to how I would understand the term “version control”]