hw: Restructure maintained files to allow for versioning

[elsalahy]

Summary:

Re-structures the HW files to allow for expansion and multiple designs. Relates to #62

Changes:

• Update structure to allow for versioning

Notes for Reviewers:

After discussion with @azerimaker

Release Notes: (optional)

...

[elsalahy]

Also solves the lib path issue and allows the user to use the project without needing to re-configure the path of the library.

[elsalahy]

Thanks @azerimaker @johanstokking, any comments on this re-structure?

[elsalahy]

@johanstokking Yes, this restructure will allow @azerimaker or me to maintain the HW files in a professional manner. I studied multiple repos and our current structure doesn't allow for expansion and multiple designs.

The main one is this from a guy working in KiCAD, if you observe how he uses a clean design to maintain the PCB folder and pushes extra files in releases.

We decided to take a similar approach with slight modification.

The new design is as follows:

• fab is for fabrication of specific device versions and will only be updated when the device goes for fabrication.
• pcb-stm32wl is where someone will develop and maintain the GN KiCAD project. (@azerimaker or other developer can add other PCBs and designs in a similar fashion pcb-xxxxx)
• sch is for schematics PDFs of the fabricated versions, and it is the first place developers go to when developing any FW for the device.
• lib is the library used to support any pcb-xxxxxx project.

[elsalahy]

@azerimaker can you check the final commit and let me know and approve if all looks good?

[elsalahy]

@azerimaker can you please check?

[elsalahy]

@johanstokking any thoughts before I merge?

[johanstokking]

But now you are introducing version numbers in the folders, right? So we get versioning in the file system, while we are using a version control system?

[elsalahy]

@johanstokking yeah it is not ideal, I was thinking of avoiding this by taking an alpha release with every version of the HW.

This would mean, we have fab and sch with no versioned folders inside.

Similar to this guy https://github.com/diegoherranz/steppenprobe/releases

If this sound better, we will do it this way, what do you think?

End goal is to maintain a snapshot of production files.

[johanstokking]

I was thinking of avoiding this by taking an alpha release with every version of the HW.

I don't understand

This would mean, we have fab and sch with no versioned folders inside.

I don't understand either, what is fab and sch?

Similar to this guy diegoherranz/steppenprobe/releases

What can I see here?

[elsalahy]

@johanstokking

We can avoid having the below folder naming by tagging an alpha release. https://github.com/TheThingsIndustries/st-node/tree/feature/hw-restructure/Hardware/sch/v0.1

fab and sch are the only folders where there is a folder versioning for production

You can observe how he handles the Gerber, bom and pdf files only as part of a release.

[johanstokking]

Yes, that is naturally how things work on Git; versioning is not in the file system but in tags, and you can release tags with collateral.

Therefore I wonder why we use version numbers in folder names.

[elsalahy]

@johanstokking yes, you are right and this is the method I preferred, but it seems HW developers have a different preference as @azerimaker highlighted to me.

So we had two options on handling HW production files and we implemented one of them.

I re-worked it now and we can observe how the community of HW engineers will react to this structure/process.

Can you please check again and let me know what you think?

@azerimaker can you also check the new structure?

[johanstokking]

but it seems HW developers have a different preference as @azerimaker highlighted to me.

I'm curious to know why.

[azerimaker]

@johanstokking, the only reason why we did that, is because the changes from v0.1 to v0.2 was quite drastic, in terms of PCB design, but we still can use GitHub's internal versioning and get rid of the versioned folders altogether.

[elsalahy]

@johanstokking is this ok to merge?

[johanstokking]

Yes