Establish firmware flashing behavior based on semantic versioning

[ryanfobel]

Problem

One of the problems with our current base-node-rpc firmware/driver scheme is that in order to guarantee that a host will be able to communicate with a node, they both need to have the same version. To make this guarantee, we have been updating the firmware on each connect, however this leads to lots of unnecessary flashing if the firmware has not changed.

Proposed solution

If we follow semantic versioning for these packages and consider the API as the methods exposed (i.e., changes in the protocol), we could avoid flashing firmware in the case of micro version differences. We could even enforce this versioning policy (e.g., via a git hook) by looking for changes to the generated protocol files.

[cfobel]

I like this suggestion. Sounds like a great idea.

…

On Sat, Aug 5, 2017, 12:05 PM Ryan Fobel ***@***.***> wrote: Problem One of the problems with our current base-node-rpc firmware/driver scheme is that in order to guarantee that a host will be able to communicate with a node, they both need to have the same version. To make this guarantee, we have been updating the firmware on each connect, however this leads to lots of unnecessary flashing if the firmware has not changed. Proposed solution If we follow semantic versioning <http://semver.org/> for these packages and consider the API as the methods exposed (i.e., changes in the protocol), we could avoid flashing firmware in the case of micro version differences. We could even enforce this versioning policy (e.g., via a git hook) by looking for changes to the generated protocol files. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#8>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAyQO6GdXaJwOwgpwuyVlFdbMuiObJD-ks5sVJLQgaJpZM4OufuZ> .