Add rfc 0010 node software updates #54
Conversation
|
|
||
| ## Motivation | ||
|
|
||
| To create a safe environment throughout the blockchain network, software update guidelines are extremely important. All nodes must be updated at a certain interval to ensure safe operation. However, the actual process is quite complex as the entire network must be considered. |
There was a problem hiding this comment.
Like always, missing semantic line breaks 😄
|
|
||
| ## Examples & Best Practices | ||
|
|
||
| Based on the version system there could be different protocols to update a node. If the software of the blockchain nodes follows the [semantic versioning](https://semver.org/) protocol, MINOR and PATCH updates should be updatable without breaking the network functionality. For major patches a coordinated update has to be planned and can lead to a short downtime of the network because of a change in the communication protocol. |
There was a problem hiding this comment.
Talking about soft- and hard-forks here? I would assume those two classes of updates are, in a certain way, the way of the blockchain community to introduce protocol updates at least.
| TGB, and b) accepted by a vote of any other relevant Sovrin Governing Body (such as | ||
| the Steward Council). | ||
|
|
||
| A clear and strict protocol has to be defined to avoid accidents like the [Überlingen mid-air collision](https://en.wikipedia.org/wiki/2002_%C3%9Cberlingen_mid-air_collision) where the involved parties followed different suggestions. |
There was a problem hiding this comment.
I never heard this example being mentioned in the context of software updates, can you give references of how this is part of the IT industry consciousness? 🙂
| - Versioning | ||
| - Minor updates without interrupting the network | ||
| - Major updates should be planned | ||
| - Guaranteed availability of the system |
There was a problem hiding this comment.
Not guarantees, but target SLAs.
| ## Specification | ||
|
|
||
| - Update protocol | ||
| - Versioning |
There was a problem hiding this comment.
| - Versioning | |
| - Version Schema |
There was a problem hiding this comment.
Plus consequences of versioning, e.g. what is considered a breaking change, etc.
| - Minor updates without interrupting the network | ||
| - Major updates should be planned |
There was a problem hiding this comment.
| - Minor updates without interrupting the network | |
| - Major updates should be planned | |
| - Protocols for major and minor updates. |
Comments are very welcome.