From 0f26f62db52578336829c099139bda0997770c90 Mon Sep 17 00:00:00 2001 From: Ulfat Date: Thu, 26 May 2022 17:20:12 +0500 Subject: [PATCH 1/3] Set upgrade handler for dcl v0.11.0 --- app/app.go | 7 +++++++ 1 file changed, 7 insertions(+) diff --git a/app/app.go b/app/app.go index 57b5dfca1..fdf65e317 100644 --- a/app/app.go +++ b/app/app.go @@ -593,6 +593,13 @@ func New( }, ) + app.UpgradeKeeper.SetUpgradeHandler( + "v0.11.0", + func(ctx sdk.Context, plan upgradetypes.Plan, fromVM module.VersionMap) (module.VersionMap, error) { + return make(module.VersionMap), nil + }, + ) + return app } From f344d8b88b831707765fa24b18e881318b25bb3f Mon Sep 17 00:00:00 2001 From: Ulfat Date: Thu, 26 May 2022 17:33:24 +0500 Subject: [PATCH 2/3] Add instruction to set an upgrade handler in release docs --- docs/release.md | 19 +++++++++++++++---- 1 file changed, 15 insertions(+), 4 deletions(-) diff --git a/docs/release.md b/docs/release.md index 6c50959f0..5b83122fe 100644 --- a/docs/release.md +++ b/docs/release.md @@ -1,16 +1,27 @@ # Release The steps: - -1. [draft](https://github.com/zigbee-alliance/distributed-compliance-ledger/releases/new) and publish a new GitHub release: +1. Set a new upgrade handler for the verion being released in [here](https://github.com/zigbee-alliance/distributed-compliance-ledger/blob/2ea0715e47bc911c21e0f74431a87ce68bbd5043/app/app.go#L589) before releasing the binary + + example: + ```golang + app.UpgradeKeeper.SetUpgradeHandler( + "v0.11.0", + func(ctx sdk.Context, plan upgradetypes.Plan, fromVM module.VersionMap) (module.VersionMap, error) { + return make(module.VersionMap), nil + }, + ) + ``` + > **_Note:_** Dummy handler is added in this example. But you may want to run some migrations inside the handler. +2. [draft](https://github.com/zigbee-alliance/distributed-compliance-ledger/releases/new) and publish a new GitHub release: * specify a new release tag based on a new planned version of DCLedger in the format `v` (e.g. `v1.2.3` for the version `1.2.3`) * verify the branch/commit target for the release: usually it should be `master` but other targets are possible as well * put release notes -2. once published [release pipeline](https://github.com/zigbee-alliance/distributed-compliance-ledger/actions/workflows/release.yml) is triggered: +3. once published [release pipeline](https://github.com/zigbee-alliance/distributed-compliance-ledger/actions/workflows/release.yml) is triggered: * it builds `dcld` binary on `ubuntu-20.04` and `macos-11` and attaches the artifacts to the GitHub release: * binary and archived binary for `ubuntu-20.04` * archived binary for `macos-11` * systemd service file -3. additional way to trigger the pipeline is to do that manually, it can be used for the following cases: +4. additional way to trigger the pipeline is to do that manually, it can be used for the following cases: * some intermittent issue happened during the normal build so some artifact hasn't been attached * testing / debugging From 5e1150726b2dd6268ce36105f2bab8e2ccc77ea8 Mon Sep 17 00:00:00 2001 From: Ulfat Date: Thu, 26 May 2022 17:53:49 +0500 Subject: [PATCH 3/3] Update docs/release.md Co-authored-by: Alexander Shcherbakov --- docs/release.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/release.md b/docs/release.md index 5b83122fe..c190984b6 100644 --- a/docs/release.md +++ b/docs/release.md @@ -1,7 +1,7 @@ # Release The steps: -1. Set a new upgrade handler for the verion being released in [here](https://github.com/zigbee-alliance/distributed-compliance-ledger/blob/2ea0715e47bc911c21e0f74431a87ce68bbd5043/app/app.go#L589) before releasing the binary +1. Set a new upgrade handler for the version being released in [here](https://github.com/zigbee-alliance/distributed-compliance-ledger/blob/2ea0715e47bc911c21e0f74431a87ce68bbd5043/app/app.go#L589) before releasing the binary example: ```golang