From 4df6d5d84d05dd5cb573c6026ed6dbee617da870 Mon Sep 17 00:00:00 2001 From: MSalopek Date: Mon, 9 Dec 2024 10:34:49 +0100 Subject: [PATCH] docs: update ADRs intro and fault resolution adr position and title --- ...utions.md => adr-021-fault-resolutions.md} | 4 +- docs/docs/adrs/intro.md | 1 + .../migrations/keeping-up-with-sdk.md | 43 ------------------- 3 files changed, 3 insertions(+), 45 deletions(-) rename docs/docs/adrs/{adr-019-fault-resolutions.md => adr-021-fault-resolutions.md} (99%) delete mode 100644 docs/internal/migrations/keeping-up-with-sdk.md diff --git a/docs/docs/adrs/adr-019-fault-resolutions.md b/docs/docs/adrs/adr-021-fault-resolutions.md similarity index 99% rename from docs/docs/adrs/adr-019-fault-resolutions.md rename to docs/docs/adrs/adr-021-fault-resolutions.md index d90b12652d..45ff16ba0a 100644 --- a/docs/docs/adrs/adr-019-fault-resolutions.md +++ b/docs/docs/adrs/adr-021-fault-resolutions.md @@ -1,8 +1,8 @@ --- -sidebar_position: 20 +sidebar_position: 21 title: Fault Resolutions --- -# ADR 019: Fault Resolutions +# ADR 021: Fault Resolutions ## Changelog * 17th July 2024: Initial draft diff --git a/docs/docs/adrs/intro.md b/docs/docs/adrs/intro.md index 3e31c60704..86bef29325 100644 --- a/docs/docs/adrs/intro.md +++ b/docs/docs/adrs/intro.md @@ -52,6 +52,7 @@ To suggest an ADR, please make use of the [ADR template](https://github.com/cosm - [ADR 017: ICS with Inactive Provider Validators](./adr-017-allowing-inactive-validators.md) - [ADR 018: Fault Resolutions](./adr-018-fault-resolutions.md) - [ADR 021: Consumer Chain Clients](./adr-021-consumer-chain-clients.md) +- [ADR 021: Fault Resolutions](./adr-021-fault-resolutions.md) ### Rejected diff --git a/docs/internal/migrations/keeping-up-with-sdk.md b/docs/internal/migrations/keeping-up-with-sdk.md deleted file mode 100644 index 9eeab0d8e8..0000000000 --- a/docs/internal/migrations/keeping-up-with-sdk.md +++ /dev/null @@ -1,43 +0,0 @@ -# Keeping up with CosmosSDK releases - -Our general approach for minor version cosmos-sdk upgrades (e.g. v0.47.x -> v0.50.x): -Cosmos-sdk and IBC are updated at the same lockstep. This is done because every ibc-go version has a corresponding cosmos-sdk version. - -Our process starts with a "spike" phase that is capped at 2 weeks. During this "spike" we attempt the upgrade by bumping the deps and checking if the upgrade is smooth. This phase can be extended, depending on the complexity of the upgrade. - -This allows us to detect any unforeseen issues and triage them before committing to a release date. - -Upon the completion of the "spike", most of our custom application logic (modules) is already upgraded and functioning and that leaves us in a state where we have to modify the testing frameworks, app boilerplate and various other auxiliary systems (CI pipelines etc.). - -This phase as involves a lot of manual work and rewrites. One significant time drain is due to the need to update most of the test files to reflect API changes. Sometimes the tests need to be rewritten to be updated because of the amount of breaking changes. - -## Methodology - -We found it most efficient to always have a development branch that includes the latest cometbft/cosmos-sdk/ibc-go changes. This branch is continually updated and part of CI integrations. - -This does not come without issues, becasue the branch needs to be kept in sync with the main branch. Essentially, this forces you to backport features into the development branch so it is ready to be marked as `main` at all times. - -## Affected dependencies -* cosmos-sdk -* cometbft -* ibc-go -* cosmwasm - -## Areas of work - -### Application libraries - -Major deps upgrades cause breaking changes in the chain's custom application logic. These changes often require need manual attention (code changes) and corresponding migrations - -### - -In case of deps upgrades, it is sometimes required to write custom migration code. Some changes are outlined in the cosmos-sdk/ibc-go upgrade documentation, but oftentimes this is left up to the chain's developers. - - -### Managing forks -In case of deps upgrades, it is sometimes required to write custom migration code on your forks. -We recommend frequent syncs with the released mainline version. - - -## Updating app boilerplate -This is usually the least time-consuming phase. Extra attention should be paid to IBC transfer stacks, order of execution in BeginBlock and EndBlock and similar. Linting tools are very helful in automating this process.