Mukan Erkin Törük
20afb5db80
Some checks failed
Build SimApp / build (amd64) (push) Waiting to run
Build SimApp / build (arm64) (push) Waiting to run
CodeQL / Analyze (push) Waiting to run
Build & Push / build (push) Waiting to run
Run Gosec / Gosec (push) Waiting to run
Lint / golangci-lint (push) Waiting to run
Checks dependencies and mocks generation / Check go mod tidy (push) Waiting to run
Checks dependencies and mocks generation / Check up to date mocks (push) Waiting to run
System Tests / setup (push) Waiting to run
System Tests / test-system (push) Blocked by required conditions
System Tests / test-system-legacy (push) Blocked by required conditions
Tests / Code Coverage / split-test-files (push) Waiting to run
Tests / Code Coverage / tests (00) (push) Blocked by required conditions
Tests / Code Coverage / tests (01) (push) Blocked by required conditions
Tests / Code Coverage / tests (02) (push) Blocked by required conditions
Tests / Code Coverage / tests (03) (push) Blocked by required conditions
Tests / Code Coverage / test-integration (push) Waiting to run
Tests / Code Coverage / test-e2e (push) Waiting to run
Tests / Code Coverage / repo-analysis (push) Blocked by required conditions
Tests / Code Coverage / test-sim-nondeterminism (push) Waiting to run
Tests / Code Coverage / test-clientv2 (push) Waiting to run
Tests / Code Coverage / test-core (push) Waiting to run
Tests / Code Coverage / test-depinject (push) Waiting to run
Tests / Code Coverage / test-errors (push) Waiting to run
Tests / Code Coverage / test-math (push) Waiting to run
Tests / Code Coverage / test-schema (push) Waiting to run
Tests / Code Coverage / test-collections (push) Waiting to run
Tests / Code Coverage / test-cosmovisor (push) Waiting to run
Tests / Code Coverage / test-confix (push) Waiting to run
Tests / Code Coverage / test-store (push) Waiting to run
Tests / Code Coverage / test-log (push) Waiting to run
Tests / Code Coverage / test-x-tx (push) Waiting to run
Tests / Code Coverage / test-x-nft (push) Waiting to run
Tests / Code Coverage / test-x-circuit (push) Waiting to run
Tests / Code Coverage / test-x-feegrant (push) Waiting to run
Tests / Code Coverage / test-x-evidence (push) Waiting to run
Tests / Code Coverage / test-x-upgrade (push) Waiting to run
Tests / Code Coverage / test-tools-benchmark (push) Waiting to run
Build & Push SDK Proto Builder / build (push) Has been cancelled
83 lines
2.5 KiB
Markdown
83 lines
2.5 KiB
Markdown
# ADR {ADR-NUMBER}: {TITLE}
|
|
|
|
## Changelog
|
|
|
|
* {date}: {changelog}
|
|
|
|
## Status
|
|
|
|
{DRAFT | PROPOSED} Not Implemented
|
|
|
|
> Please have a look at the [PROCESS](./PROCESS.md#adr-status) page.
|
|
> Use DRAFT if the ADR is in a draft stage (draft PR) or PROPOSED if it's in review.
|
|
|
|
## Abstract
|
|
|
|
> "If you can't explain it simply, you don't understand it well enough." Provide
|
|
> a simplified and layman-accessible explanation of the ADR.
|
|
> A short (~200 word) description of the issue being addressed.
|
|
|
|
## Context
|
|
|
|
> This section describes the forces at play, including technological, political,
|
|
> social, and project local. These forces are probably in tension, and should be
|
|
> called out as such. The language in this section is value-neutral. It is simply
|
|
> describing facts. It should clearly explain the problem and motivation that the
|
|
> proposal aims to resolve.
|
|
> {context body}
|
|
|
|
## Alternatives
|
|
|
|
> This section describes alternative designs to the chosen design. This section
|
|
> is important and if an adr does not have any alternatives then it should be
|
|
> considered that the ADR was not thought through.
|
|
|
|
## Decision
|
|
|
|
> This section describes our response to these forces. It is stated in full
|
|
> sentences, with active voice. "We will ..."
|
|
> {decision body}
|
|
|
|
## Consequences
|
|
|
|
> This section describes the resulting context, after applying the decision. All
|
|
> consequences should be listed here, not just the "positive" ones. A particular
|
|
> decision may have positive, negative, and neutral consequences, but all of them
|
|
> affect the team and project in the future.
|
|
|
|
### Backwards Compatibility
|
|
|
|
> All ADRs that introduce backwards incompatibilities must include a section
|
|
> describing these incompatibilities and their severity. The ADR must explain
|
|
> how the author proposes to deal with these incompatibilities. ADR submissions
|
|
> without a sufficient backwards compatibility treatise may be rejected outright.
|
|
|
|
### Positive
|
|
|
|
> {positive consequences}
|
|
|
|
### Negative
|
|
|
|
> {negative consequences}
|
|
|
|
### Neutral
|
|
|
|
> {neutral consequences}
|
|
|
|
## Further Discussions
|
|
|
|
> While an ADR is in the DRAFT or PROPOSED stage, this section should contain a
|
|
> summary of issues to be solved in future iterations (usually referencing comments
|
|
> from a pull-request discussion).
|
|
>
|
|
> Later, this section can optionally list ideas or improvements the author or
|
|
> reviewers found during the analysis of this ADR.
|
|
|
|
## Test Cases [optional]
|
|
|
|
Test cases for an implementation are mandatory for ADRs that are affecting consensus
|
|
changes. Other ADRs can choose to include links to test cases if applicable.
|
|
|
|
## References
|
|
|
|
* {reference link}
|