[napowderly]

I am curious to hear that you dont see any value in bringing software workflow to hardware. I found in previous jobs we spent a huge fraction of our time dealing with things like release, version management and reviews. Thanks for your thoughts!

[crote]

The value is mostly in the software workflow, not in the software tooling.

Store your KiCad files in Git. Make a script which automatically adds a revision tag to the PCB. Create a CI pipeline for Gerber generation. Export PNGs so you can do visual diffs.

If you're collaborating on some project which consists of artwork made in Photoshop you aren't looking for a text-based drawing program either - you are looking for a better way to do diffs.

[robomartin]

Here's something that has been true for decades: Storage is cheap and always getting cheaper.

When you are dealing with complex multidisciplinary designs (a full machine), the concept or a release takes-on a very different meaning.

Scenario: You update a single circuit board, or the code that runs on a single microprocessor.

The release descriptor for the product, the machine, must include every single element that goes into making that machine. If all you do is commit the software update to Git, you very well run a chance to create a very serious problem for manufacturing, qualification, testing and post-sales support.

It has been my experience that, because storage is cheap, a release due to any change is a full annotated copy of all design files for the entire design; electrical, firmware, software, mechanical, testing, manufacturing, etc. In some cases we've had to save entire virtual machines with working code because workstation and system software can mutate and things break. We recently had a case where a Windows 10 automatic update (don't get me started) broke code that used to work in a last month's Windows version.

If we accept that storage is cheap, then the concept of releases at the product level, are simple copies along with a set of relevant "readme" files describing release details. You can come back to this three years later and all is well.

In the era of little Arduino boards it is sometimes easier that, more often than not, electronics don't exist just for the sake of electronics but rather as part of a much larger, and often far more complex, multidisciplinary product. In that context, schematic entry is an insignificant burden. The same is true of hyperventilating about what code editor to use. Some of these things are truly rounding errors in the product life cycle.