-
Notifications
You must be signed in to change notification settings - Fork 95
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
feat(release strategy): Add archway protocol versioning and release strategy #303
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The final scenario needs to be further reviewed and discussed...
I completely see and understand the validity of such a scenario, but I do have concerns about running mainnet and public testnet on "different versions"; in this case it is something small and insignificant enough that it does not warrant an upgrade to mainnet. However, we should attempt to prevent any such scenarios from occurring at any sort of frequency as it may lead to complacency where the divergence between the two may come back to bite us;
For this reason I believe that if any such scenarios are identified or do occur, it should be taken into consideration for our formal verification process to detect and prevent any future such occurrences; i.e. any fixes required to testnet should precede deployment to mainnet so that both networks run the same version post release upgrade;
Agreed. The scenario merely presents an example hot-fix situation which is un-planned and unexpected. In normal ideal operations these situations will not occur. |
releasing-archway.md
Outdated
|
||
#### constantine-1 needs a network upgrade that only applied to constantine-1 | ||
|
||
Imagine we need to adjust 'const' (cost is the stake denom for constantine-1) token supply for constantine-1 and this requires an upgrade handler (TODO: Add link to upgrade handler description) specifically for constantine-1 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
As mentioned in the above comment, for this situation, I think it would be best to export current constantine-1
state and adjust the token supply and start constantine-2
with the fixed state
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This network is being used by dapp developers as a canary network. My only concern here is, would doing a state export imply that dapp developers would need to deploy all the daps again?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No idts. export and import also handles the contract binaries and its state as well
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Verifying the porposed workflow, will update the scenerio accordingly
…fix situations for constantin-1 and archway-1
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM (pending fixing the automated checks)
This is a collaborative PR to converge on a comprehensive release strategy for archway protocol.