search

tigard-tools / tigard

An FTDI FT2232H-based multi-protocol tool for hardware hacking
Other
592 stars 72 forks source link

document V0.0 rework #11

Closed securelyfitz closed 4 years ago

securelyfitz commented 4 years ago

What's the best place to do this? Release notes? somewhere else?

It won't matter much for all four V0.0 boards, but when new changes come around to future revisions, it would be helpful to have documentation somewhere for assembly/rework/functionality notes for them.

For V0.0, currently:

fharding1 commented 4 years ago

I tagged 289bb13b87d6e076d185519fd003d9ced033bb32 as v0.0, when we finish this next revision we can tag that commit as v0.1 (or whatever), look at all the commits between them, and annotate that tag with all the changes from v0.0.

I put those known issues in the v0.0 release (feel free to edit): https://github.com/fharding1/tigard/releases/tag/v0.0

securelyfitz commented 4 years ago

The level of detail i'm looking for is "If you want to get this working on a V0.0 board, solder an X ohm resistor between pin y of component z, as shown in the picture" Where should that be captured?

fharding1 commented 4 years ago

@securelyfitz oh, I see. I think maybe we could add an "upgrade" section to the v0.1 release that documents how to bodge the previous revision. Were you thinking of doing this for all revisions, or just production (major revision > 0)?

I like semver's philosophy on this (even though we're not using true semver), it documents that "Major version zero (0.y.z) is for initial development. Anything MAY change at any time. The public API SHOULD NOT be considered stable." Which when applied here would pretty much imply if you got your hands on a major rev 0 board you shouldn't expect it to work or be well documented.