Skip to content

[WIP] Add more methods to _Deployments contract allowing for multiple versions#182

Open
netoneko wants to merge 1 commit intomasterfrom
feature/upgradable-deployments
Open

[WIP] Add more methods to _Deployments contract allowing for multiple versions#182
netoneko wants to merge 1 commit intomasterfrom
feature/upgradable-deployments

Conversation

@netoneko
Copy link
Copy Markdown
Contributor

@netoneko netoneko commented Sep 15, 2019

Proposed new methods:

deployVersion() // called after deployService
getVersion() // returns latest version number

allowVersioning()
disallowVersioning()

transferOwnership()
acceptOwnership()

In this model there is no way to completely remove versioning that might be a bit tricky.

Also, there is no migration method in the contract, which also might be problematic.

This PR is a preparation for brainstorming meeting with OdedW

@netoneko netoneko requested a review from OdedWx September 15, 2019 14:11
@netoneko netoneko force-pushed the feature/upgradable-deployments branch from 9b8601e to d28cf75 Compare September 16, 2019 07:14
@netoneko netoneko force-pushed the feature/upgradable-deployments branch from d28cf75 to 35cc850 Compare September 16, 2019 08:44
Copy link
Copy Markdown
Contributor

@ronnno ronnno left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If we avoid dealing with state upgrades, I'd at least leave some hooks for manual upgrade code in case it's needed:

  1. specify that state persists across contract versions
  2. define some callback hook in each contract that can perform state upgrades if needed
    ?

* Read code from state key `<name>.Code.<counter>` by calling `State.ReadUint32ByKey`.
* Returns `0` if the contract was not deployed

## `allowVersioning` (method)
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

is there a sense in separating governance concerns to a separate contract? this way a chain owner could deploy the policy contract so that each chain can be configured with different upgrade policy (ie, upgrade delays, upgrade by voting, upgrade appeals, permissions etc..)

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, I think policy contract is a great idea.

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.

3 participants