Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Allow to create separate upgrade schedules for different chain ids #12099

Open
jancionear opened this issue Sep 16, 2024 · 0 comments
Open

Allow to create separate upgrade schedules for different chain ids #12099

jancionear opened this issue Sep 16, 2024 · 0 comments
Assignees
Labels
C-enhancement Category: An issue proposing an enhancement or a PR with one.

Comments

@jancionear
Copy link
Contributor

jancionear commented Sep 16, 2024

A ProtocolUpgradeVotingSchedule defines when neard starts voting for new protocol versions. The voting date is set globally, no matter whether it's mainnet, testnet or something else. Because of that we have to make release-specific commits for every testnet and mainnet release. First we have a commit that sets the voting date for testnet, then a commit which removes the testnet voting date and sets the mainnet voting date.

I think it'd be nicer if we could have separate upgrade schedules for each chain id - we could say that testnet should vote at this time and mainnet should vote at this one.

Advantages:

  • Less chaotic code which removes and sets voting dates on the release branchs
  • Harder to make a mistake and e.g set a testnet voting date in a mainnet release
  • Ability to run protocol upgrade tests on the exact version of neard that is published in the release. Currently integration tests fail when the protocol version is set, AFAIK we also have to change something about it for mocknet tests. With per-chain protocol upgrades this wouldn't be a problem - there would be no voting date set for localnet and mocknet chains.
  • Ability to release the same release to both testnet and mainnet. For example with 2.2.1 we had to make a separate testnet release (2.2.1-rc.1) just to set a different voting date. With per-chain schedules we could release 2.2.1 to both mainnet and testnet.
@jancionear jancionear added the C-enhancement Category: An issue proposing an enhancement or a PR with one. label Sep 16, 2024
@jancionear jancionear self-assigned this Sep 16, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
C-enhancement Category: An issue proposing an enhancement or a PR with one.
Projects
None yet
Development

No branches or pull requests

1 participant