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

feat(release strategy): Add archway protocol versioning and release strategy #303

Merged
merged 7 commits into from
Mar 15, 2023

Conversation

shahbazn
Copy link
Contributor

@shahbazn shahbazn commented Mar 1, 2023

This is a collaborative PR to converge on a comprehensive release strategy for archway protocol.

  • Please feel free to add new sections to the PR as needed
  • To change existing sections please add ideas as comments. Once an agreement has reached in comments, please free to push changes to existing sections.

releasing-archway.md Outdated Show resolved Hide resolved
releasing-archway.md Outdated Show resolved Hide resolved
releasing-archway.md Outdated Show resolved Hide resolved
Copy link
Contributor

@zanicar zanicar left a 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;

@shahbazn
Copy link
Contributor Author

shahbazn commented Mar 3, 2023

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 Show resolved Hide resolved
releasing-archway.md Outdated Show resolved Hide resolved
releasing-archway.md Outdated Show resolved Hide resolved

#### 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
Copy link
Contributor

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

Copy link
Contributor Author

@shahbazn shahbazn Mar 3, 2023

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?

Copy link
Contributor

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

Copy link
Contributor Author

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

releasing-archway.md Outdated Show resolved Hide resolved
releasing-archway.md Show resolved Hide resolved
releasing-archway.md Show resolved Hide resolved
releasing-archway.md Outdated Show resolved Hide resolved
releasing-archway.md Show resolved Hide resolved
…fix situations for constantin-1 and archway-1
@loverdos loverdos requested review from loverdos and removed request for loverdos March 9, 2023 18:04
@loverdos loverdos marked this pull request as ready for review March 9, 2023 18:07
@loverdos loverdos self-requested a review March 9, 2023 18:08
Copy link

@loverdos loverdos left a 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)

@shahbazn shahbazn merged commit 581c060 into main Mar 15, 2023
@shahbazn shahbazn deleted the release-strategy branch March 15, 2023 10:46
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

7 participants