Sanjay
@sanjay
Thinking about the upgrade process for Snapchain and looking for feedback. There are going to be two kinds of changes: a) Soft forks (bug fixes, minor improvements and non-consensus breaking changes) b). Hard forks (breaking changes, typically FIP implementations or other major changes that affects consensus)
2 replies
5 recasts
37 reactions
Sanjay
@sanjay
a) will be released as a patch release (0.1.1 -> 0.1.2) and node operators can upgrade at their own pace. No impact if you choose not to upgrade b) will be released as a minor version upgrade (0.1.1 -> 0.2.0) and operators must upgrade before a certain time, otherwise their node will halt.
2 replies
0 recast
8 reactions
Sanjay
@sanjay
If you are a node operator, would be interested in your feedback on 1. How much heads up do you need for minor version upgrades? 1 week? 2 weeks? 2. How would you like to be notified? Snapchain channel? Github issue/post? Something else? 3. Any other feedback (keep fixed schedule like hubs or do it ad-hoc?)
3 replies
0 recast
3 reactions
Greg
@greg
1. if no breaking changes, 1 week seems fine. longer with significant changes 2. something i can subscribe to get notifications from. warpcast group, telegram channel, email for the boomers, etc. github issue doesn’t seem right 3. with hubs, how many of the scheduled version bumps had meaningful upgrades vs not? if most are just empty for the sake of process, that seems unnecessary
3 replies
0 recast
5 reactions
androidsixteen 🌲
@androidsixteen.eth
1. For soft forks (patch releases), <1 week is fine, provided it doesn’t compound (multiple versions released in short succession). For minor releases, prob min 2 weeks because it will be a production dependency and harder for small teams to drop all work in flight for an upgrade unless it’s just DL the binary and not much work needed 2. You should create a group for all node operators and have comms in there. Historically have seen chains use a private discord channel, but slack is probably fine. Will be particularly useful as quorum sizes grow and if any issues arise that break consensus (speed to communicate to all parties will be important) 3. Telegraph big changes, you probably won’t be able to avoid hot fixes as time goes on, so strict SLA is not needed. Would also suggest having one person run point for validator comms (like a validator dev rel) that everyone knows is the specified cat herder cc @giu if I missed anything
0 reply
0 recast
2 reactions
christopher
@christopher
1. Probably a day or so. 2. Group chat has worked well and kept chatter on the TL low. 3. We should rapidly release before we move to a fixed schedule. But things seem moderately stable rn.
0 reply
0 recast
1 reaction
