Files
cosmos-sdk/docs/architecture
47dd07d4ff Modify IBC client governance unfreezing to reflect ADR changes (#8405)
* update proto files

* make proto-gen

* update clienttypes

* update localhost and solo machine

* refactor tm client proposal handling

* copy metadata

* self review fixes

* update 02-client keeper tests

* fix 02-client type tests

* fix localhost and solomachine tests

* begin updating tm tests

* partially fix tm tests

* increase codecov

* add more tests

* add changelog

* update specs

* add docs

* fix test

* modify adr

* allow modified chain-ids

* add CLI command

* fix typos

* fix lint

* Apply suggestions from code review

Co-authored-by: Federico Kunze <31522760+fedekunze@users.noreply.github.com>

* update docs, rm example

* Update docs/ibc/proposals.md

Co-authored-by: Christopher Goes <cwgoes@pluranimity.org>

* update height checks to reflect chain-id changes cc @AdityaSripal

* Apply suggestions from code review

Co-authored-by: Christopher Goes <cwgoes@pluranimity.org>

* Apply suggestions from code review

Co-authored-by: Aditya <adityasripal@gmail.com>

* address most of @AdityaSripal suggestions

* update docs per review suggestions

* Update x/ibc/core/02-client/types/proposal.go

* add proposal handler

* register proposal type

* register proposal on codec

* fix routing

Co-authored-by: Federico Kunze <31522760+fedekunze@users.noreply.github.com>
Co-authored-by: Christopher Goes <cwgoes@pluranimity.org>
Co-authored-by: Aditya <adityasripal@gmail.com>
2021-02-16 15:31:40 +00:00
..
2020-01-15 08:14:25 +01:00
2020-10-22 22:40:44 +00:00
2021-02-04 18:09:28 -08:00

order, parent
order parent
false
order
false

Architecture Decision Records (ADR)

This is a location to record all high-level architecture decisions in the Cosmos-SDK.

An Architectural Decision (AD) is a software design choice that addresses a functional or non-functional requirement that is architecturally significant. An Architecturally Significant Requirement (ASR) is a requirement that has a measurable effect on a software system’s architecture and quality. An Architectural Decision Record (ADR) captures a single AD, such as often done when writing personal notes or meeting minutes; the collection of ADRs created and maintained in a project constitute its decision log. All these are within the topic of Architectural Knowledge Management (AKM).

You can read more about the ADR concept in this blog post.

Rationale

ADRs are intended to be the primary mechanism for proposing new feature designs and new processes, for collecting community input on an issue, and for documenting the design decisions. An ADR should provide:

  • Context on the relevant goals and the current state
  • Proposed changes to achieve the goals
  • Summary of pros and cons
  • References
  • Changelog

Note the distinction between an ADR and a spec. The ADR provides the context, intuition, reasoning, and justification for a change in architecture, or for the architecture of something new. The spec is much more compressed and streamlined summary of everything as it stands today.

If recorded decisions turned out to be lacking, convene a discussion, record the new decisions here, and then modify the code to match.

Creating new ADR

Read about the PROCESS.

ADR Table of Contents

Accepted

Proposed