Spec release process

[ilblackdragon]

Original suggestion:

• Spec release every month, version X
• Clients release every month with 1 month offset from spec. E.g. 1 month from spec release X, clients vX are released.

This requires:

• Spec has a list of clients that are “supported” - e.g. which release schedule is syncronized. If some client team is not on schedule, issues, etc -> they can be removed from “supported” list. Also can apply via PR to supported list if already following requirements.
• Spec changes already have pull requests to clients that are enough to understand scope of work at least. E.g. if it’s something trivial, then only to one client PR is required, if it’s something substantial - then to all supported clients.

Questions from @bowenwang1996

Refined suggestion:

• Spec “stable” release every month, vX
• Clients release at the same time with vX spec.

Still same idea with “supported” clients.

You submit PR to spec repo, it gets reviewed, debated and marked as “implementing” after acceptance.

This means all clients start developing it. After changes are merged into “master” in all supported clients -> spec PR is merged into “master”. (e.g. there is a checklist in PR that is required to have all supported clients PRs linked and merged).
Note that while implementing spec might change due to discovered implementation details or due to testing / benchmarking.

After that have the usual stabilization month on clients side and released together spec + clients.

If some client implementation is consistently lagging - they will be cut from “support” list.

[bowenwang1996]

So I guess that means all clients have to have the same release cycle? Also we will need some overall triage as to which spec change gets implemented first. One potential problem is that there might be conflicting changes in different PRs to the spec which may result in undesirable consequences.

[ilblackdragon]

Yes, I think all clients should be on the same protocol changes schedule.
Because I don't think spec should be really changed without client development teams accepting this change.

In the 2nd option, such unintended consequences that can not be fixed within reasonable period of time - it get rollback. Because it probably means that spec has missing pieces or wasn't thought out how it combines with another change.

Even if the issue exists only in one client - it gets rolled-back across all clients and postponed until stabilized.

I can see an alternative where we go full on-chain governance, where there is a vote on next hash of the spec and then we follow https://commonwealth.im/near/proposal/discussion/261-upgradability?comment=649 procedure for an actual update. This means client dev teams are operating independently and can upgrade whenever, and just will have community push to upgrade when new version is voted in. And if some clients are lagging - people just will switch away from them (e.g. if 70% of network switched because ClientA implemented selected change but ClientB didn't - the other 30% may decide to stop running ClientB if it's really lagging).

[bowenwang1996]

Even if we go with full on-chain governance, the compatibility between different clients should still be tested. In my vision, different clients should join the same betanet or testnet to test compatibility before they can be used in production. That means some coordination in schedule is still required.