Package Upgrade documentation #10475
Merged
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
|
The latest updates on your projects. Learn more about Vercel for Git ↗︎ |
github-actions
bot
added
the
Type: Documentation
randall-Mysten
approved these changes
Apr 6, 2023
| TransferObjects([Result(0)],Input(0)), | ||
| ] | ||
|
|
||
| Sender: <PUBLISHER-ID> |
There was a problem hiding this comment.
isn't this the address of the package owner? Is it confusing to introduce a new ID type in this topic that is used only in this topic?
doc/src/build/package-upgrades.md
Outdated
| "AddressOwner": String("<PUBLISHER-ID>"), | ||
| }, | ||
| "objectType": String("<ORIGINAL-PACKAGE-ID>::sui_package::<MODULE-NAME>"), | ||
| "objectId": String("<PUBLISHER-ID>"), |
There was a problem hiding this comment.
the objectID matches the publisher ID?
| ] | ||
| ``` | ||
|
|
||
| The result includes an **Object changes** section with two pieces of information you need for upgrading, an `UpgradeCap` ID and your package ID. |
There was a problem hiding this comment.
does it need the packageId? And this ID is not the ORIGINAL PACKAGE ID?
|
|
||
| The result includes an **Object changes** section with two pieces of information you need for upgrading, an `UpgradeCap` ID and your package ID. | ||
|
|
||
| You can identify the different objects using the `Object.objectType` value in the response. The `UpgradeCap` entry has a value of `String("0x2::package::UpgradeCap")` and the `objectType` for the package reads `String("<PACKAGE-ID>::sui_package::<MODULE-NAME>")` |
There was a problem hiding this comment.
it calls out package ID but then says objectType - it took me a minute to see PACKAGE ID in the string. maybe call out that the objectType includes the package ID?
|
|
||
| The `published-at` value allows the Move compiler to verify dependencies against on-chain versions of those packages. | ||
|
|
||
| After a while, you decide to upgrade your `sui_package` to include some requested features. Before running the `upgrade` command, you need to edit the manifest again. In the `[addresses]` section, you update the `sui_package` address value to `0x0` again so the validator issues a new address for the upgrade package. You can leave the `published-at` value the same, because it is only read by the toolchain when publishing a dependent package. The saved manifest now resembles the following: |
There was a problem hiding this comment.
validator - Since this is a specific node type is there a different word to use here?
doc/src/build/package-upgrades.md
Outdated
| sui_package = "0x0" | ||
| ``` | ||
|
|
||
| With the new manifest and code in place, it's time to use the `sui client upgrade` command to upgrade your package. Pass the `UpgradeCap` ID to the `--upgrade-capability` flag. |
There was a problem hiding this comment.
in the example output this is UPGRADE CAP ID
doc/src/build/package-upgrades.md
Outdated
| sui_package = "<ORIGINAL-PACKAGE-ID>" | ||
| ``` | ||
|
|
||
| The `published-at` value changes with every upgrade. The ID for the `sui_package` in the `[addresses]` section always points to the original ID after upgrading. You must always change that value back to `0x0`, however, before running the `upgrade` command so the validator knows to create a new ID for the upgrade. |
sblackshear
pushed a commit
to sblackshear/sui
that referenced
this pull request
Apr 10, 2023
## Description Documentation for package upgrades. ## Test Plan Locally --- If your changes are not user-facing and not a breaking change, you can skip the following section. Otherwise, please indicate what changed, and then add to the Release Notes section as highlighted during the release process. ### Type of Change (Check all that apply) - [ ] user-visible impact - [ ] breaking change for a client SDKs - [ ] breaking change for FNs (FN binary must upgrade) - [ ] breaking change for validators or node operators (must upgrade binaries) - [ ] breaking change for on-chain data layout - [ ] necessitate either a data wipe or data migration ### Release notes
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
Description
Documentation for package upgrades.
Test Plan
Locally
If your changes are not user-facing and not a breaking change, you can skip the following section. Otherwise, please indicate what changed, and then add to the Release Notes section as highlighted during the release process.
Type of Change (Check all that apply)
Release notes