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

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

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

netoneko
Copy link
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
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
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
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.

2 participants