This repository has been archived by the owner on Jan 24, 2022. It is now read-only.
Updates documentation about json files regarding lightmode. #222
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
come-maiz
reviewed
Oct 11, 2018
packages/docs/docs/docs/advanced.md
Outdated
| The other thing to notice in these files are the version numbers (or names!). The `<appVersion>` keeps track of the latest app version, and matches `<version>` from `zos.json`. The `<proxy-i-version>`s, on the other hand, keep track of which version of the contracts the proxies are pointing to. Say you deploy a contract in your app version 1.0, and then bump the version to 1.1 and push some upgraded code for that same contract. This will be reflected in the `<contract-i-address>`, but not yet in the proxy, which will display 1.0 in `<proxy-i-version>` and the old logic contract address in `<implementation-i-address>`. Once you run `zos update` to your contract, `<proxy-i-version>` will show the new 1.1 version, and `<implementation-i-address>` will point to the new `<contract-i-address>`. | ||
| Another thing to notice in these files are the version numbers (or names!). The `<appVersion>` keeps track of the latest app version, and matches `<version>` from `zos.json`. The `<proxy-i-version>`s, on the other hand, keep track of which version of the contracts the proxies are pointing to. Say you deploy a contract in your app version 1.0, and then bump the version to 1.1 and push some upgraded code for that same contract. This will be reflected in the `<contract-i-address>`, but not yet in the proxy, which will display 1.0 in `<proxy-i-version>` and the old logic contract address in `<implementation-i-address>`. Once you run `zos update` to your contract, `<proxy-i-version>` will show the new 1.1 version, and `<implementation-i-address>` will point to the new `<contract-i-address>`. | ||
|
|
||
| Also, notice the fields `<app>` and `<package>`. These contain the addresses of contracts that ZeppelinOS uses to facilitate the creation of proxies and the management of different versions of your contracts. Unless ZeppelinOS is used in "light" mode (using the `--light` option when running the `zos init` command), it will make use of these two contracts. An `App` contains a `Package`, which keeps track of versioned `ImplementationDirectory`'s using semantic versioning. An `ImplementationDirectory` simply provides different implementations for each of your app's contracts. Note that both `<app>` and `<package>` will not exist if the ZeppelinOS is initialized in light mode. |
There was a problem hiding this comment.
This looks good to me. But, there are a few things said today that confuse me.
- @spalladino said lightweight will be the default, so the order of the paragraph should be reverted. First mention what lightweight uses, and then mention what full app uses.
- @maraoz said we shouldn't mention "lightweight" to our users for devcon. I'm not sure if that is solved by mentioning a "default mode" and a "full mode"
I'm leaving this review to Palla, because I don't have enough info to approve/reject.
There was a problem hiding this comment.
@ElOpio @ajsantander indeed, lightweight mode will now be the default for apps (libs cannot be lightweight). App, Package, and Provider will be deployed only if the user chooses to do so when running a push --full, or on the first push if the user had initialized the app as init --full.
There was a problem hiding this comment.
Reworded a bit, pls review again @ElOpio .
eternauta1337
force-pushed
the
docs-json-files-lightmode
branch
from
fa5732e
to
eb44b95
Compare
come-maiz
suggested changes
Oct 16, 2018
packages/docs/docs/docs/advanced.md
Outdated
| The other thing to notice in these files are the version numbers (or names!). The `<appVersion>` keeps track of the latest app version, and matches `<version>` from `zos.json`. The `<proxy-i-version>`s, on the other hand, keep track of which version of the contracts the proxies are pointing to. Say you deploy a contract in your app version 1.0, and then bump the version to 1.1 and push some upgraded code for that same contract. This will be reflected in the `<contract-i-address>`, but not yet in the proxy, which will display 1.0 in `<proxy-i-version>` and the old logic contract address in `<implementation-i-address>`. Once you run `zos update` to your contract, `<proxy-i-version>` will show the new 1.1 version, and `<implementation-i-address>` will point to the new `<contract-i-address>`. | ||
| Another thing to notice in these files are the version numbers. The `<appVersion>` keeps track of the latest app version, and matches `<version>` from `zos.json`. The `<proxy-i-version>`s, on the other hand, keep track of which version of the contracts the proxies are pointing to. Say you deploy a contract in your app version 1.0, and then bump the version to 1.1 and push some upgraded code for that same contract. This will be reflected in the `<contract-i-address>`, but not yet in the proxy, which will display 1.0 in `<proxy-i-version>` and the old logic contract address in `<implementation-i-address>`. Once you run `zos update` to your contract, `<proxy-i-version>` will show the new 1.1 version, and `<implementation-i-address>` will point to the new `<contract-i-address>`. | ||
|
|
||
| Also, notice the fields `<app>` and `<package>`. These contain the addresses of contracts that ZeppelinOS uses to facilitate the creation of proxies and the management of different versions of your contracts. These contracts will only be deployed when ZeppelinOS is used in "full" mode (using the `--full` option when running the `zos init` or `zos push` commands). That is, your project will not have an app or package unless explicitly using the `--full` option. Note that this mode is required for projects that produce an EVM package. For more info on the architecture of the "full" mode, see the [Contract Architecture](https://docs.zeppelinos.org/docs/architecture.html) section. |
There was a problem hiding this comment.
Note that we don't have the full flag anymore, we implemented the publish command instead.
I would say something like:
Also, notice [...]. These contracts will only be deployed once you publish your project to a desired
network. That is, your project will not have an `app` or `package` unless explicitly running the
`publish` command. Note that this step is required for projects that produce an EVM package.
To read more about the architecture of contracts we are using to publish your project on-chain
please refer to the [Contract Architecture](https://docs.zeppelinos.org/docs/architecture.html) section.
Note that I'm talking about a "step" to refer the moment you publish your code, instead of "mode" to avoid the user from thinking that ZeppelinOS can work in different modes
facuspagnuolo
approved these changes
Oct 22, 2018
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Addresses #94 Update zos json files with new CLI lightweight mode