Skip to content

Darwinia Dependency Upgrade and Communication Convention

HackFisher edited this page May 20, 2021 · 2 revisions

This document is about Darwinia node/runtime upgrade process and communication conventions, includes node, runtime definition, types, and also include darwinia.js and @darwinia/api. Following is communication convention and improve proposals for customer/client developers.

  1. The Pull Request related to Pangolin/Crab/Darwinia Runtime upgrade involves type modification or client definition (such as SignPayLoad), and its checkList needs to have a Companion PR related to darwinia.js/bridger.

  2. Before Runtime upgrade, Github Release (darwinia/darwinia-common) is required

  3. Client developers of Darainia Node and darwinia.js need to subscribe to the release of darwinia/darwinia-common/darainia.js. If a mandatory update of types is detected, they need to upgrade the version as soon as possible. (Darwinia development team can provide related tools to facilitate customers to develop subscriptions)

  4. Runtime upgrade, Crab/Darwinia will currently pass the governance module, there will be a delay time (1-2 days, reminder notification method can also be provided), there is enough time for customer developers to upgrade the dependent version. However, Pangolin, because it is a development test network, may be operated by sudo at present, and the delay is relatively short, and the customer developers may not have time. However, the customer developers are still relatively small at present, mainly relying on internal reminders and subscriptions. Production environment network.

  5. Regarding the reminder method of Release mandatory update and the Runtime delay/schedule reminder method of Crab/Darwinia, an automated tool notification (announcement/email/twitter) is required.

  6. Types-related interfaces are mainly located in darwinia.js/types.json and node/primitives.