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)

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.

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?)

Building @warpcast and @farcaster / dad / like to read, cook, ski, code

Good idea. I like it. We've just historically been allergic to major versions. Maybe time for a change.

why not just follow semver more strictly?

patch - no api changes
minor - backwards compat api changes (soft fork)
major - non backwards compat (hard fork)

seems easier to grok that version 1 and 2 are incompatible than 0.1.0 and 0.2.0 especially if using three version numbers

and also nice that you can distinguish between an upgrade that exposes new functionality or just bug fixes