You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We performed two resharding on mainnet via making targeted 1.38 release. And although this feature would not have helped a lot in that situation (as we only decided to do the second resharding after the testnet already has been resharded once), the flow of releasing one binary that has two protocol upgrades separated by two days is easier than trying to release two binaries on one week and make sure that all of the community is adopting both changes in time.
Context
We have exactly one protocol upgrade per release (it can be empty, but we still agree that we want to bump protocol version every release). As a result, this upgrade can include roll-out of several features at once. Bundling features is dangerous, and for some features it is even impossible. This creates a situation, where features developers have to be aware of each others release dates and make sure that their feature is stabilised only in the next release.
Why should NEAR One work on this
Separating feature adoptions make debugging incidents easier.
We can add new protocol feature in 1.x.1 release instead of creating 1.x+1.0 release (this part is not that important), and make the release of 1.x.1 before adoption of 1.x.0 protocol version, while giving validators ability to upgrade either before or after the first voting date (this is extremely useful).
We can massive upgrades in per-shard upgrades or separate steps. For example, moving shard boundaries without changing a number of shards in one release requires a complex development and testing of a new feature. Changing it in two steps -- split "traveling" range of accounts into separate shard, and the merge "traveling" range with "destination" range -- requires developing and testing only one new flow, that is merging of two shards.
What needs to be accomplished
From technical point of view, we need to support a vector of voting dates, and refactor
We should absolutely do this and it conveniently seems like a relatively easy task. Once it's done we should also establish some good practices around having separate versions and dates for different features within one release. The only drawback that I see is that the latter features within a release will get a little less time in testnet but that is easily fixable.
…es in one release (#11368)
Implemented the feature described in #10911.
It may or may not be needed for the congestion control and stateless
validation release but it should be useful in general and I just want to
take this variable out of the equation.
Goal
Have several protocol upgrades in one release.
Background
We performed two resharding on mainnet via making targeted 1.38 release. And although this feature would not have helped a lot in that situation (as we only decided to do the second resharding after the testnet already has been resharded once), the flow of releasing one binary that has two protocol upgrades separated by two days is easier than trying to release two binaries on one week and make sure that all of the community is adopting both changes in time.
Context
We have exactly one protocol upgrade per release (it can be empty, but we still agree that we want to bump protocol version every release). As a result, this upgrade can include roll-out of several features at once. Bundling features is dangerous, and for some features it is even impossible. This creates a situation, where features developers have to be aware of each others release dates and make sure that their feature is stabilised only in the next release.
Why should NEAR One work on this
What needs to be accomplished
From technical point of view, we need to support a vector of voting dates, and refactor
nearcore/core/primitives/src/upgrade_schedule.rs
Line 52 in f37edc0
Main use case
Links to external documentation and discussion
TODO: add link to how voting works
Estimated effort
TODO: precise estimation
This project is quite short. One engineer should be done in two weeks.
Assumptions
TODO
Pre-requisites
TODO
Out of scope
TODO
Task list
TODO
The text was updated successfully, but these errors were encountered: