* Update ADR template
The reason for this proposed update to the ADR template is twofold:
1. There's currently no easy way to cross-reference between ADRs and
issues/PRs on GitHub. This may be easy to manage for those with
context while they're working on implementing an ADR, but after time
passes and for complex ADRs it gets more difficult for newcomers to
the codebase to track both the implementation status of the ADR or
its historical context and discussions.
2. We should not allow for "proposed" ADRs. An ADR is a **decision
record**, which implies acceptance, and not a proposal. RFCs provide
a mechanism to make proposals.
Signed-off-by: Thane Thomson <connect@thanethomson.com>
* Add example of one ADR superseding another
Signed-off-by: Thane Thomson <connect@thanethomson.com>
* Move "Proposed" ToC entries to "Accepted".
It's possible some of these should actually be "Implemented", but I did not try
to go through each one to distinguish.
* Revert "Move "Proposed" ToC entries to "Accepted"."
This reverts commit d8d2907e98.
Signed-off-by: Thane Thomson <connect@thanethomson.com>
* Fix Markdown formatting
Signed-off-by: Thane Thomson <connect@thanethomson.com>
* Add "Deprecated" section to ADR TOC
Signed-off-by: Thane Thomson <connect@thanethomson.com>
* Expand ADR template to explicitly cater for rejected ADRs
Signed-off-by: Thane Thomson <connect@thanethomson.com>
Co-authored-by: M. J. Fromberger <fromberger@interchain.io>
related to: #7274 and #7275
Still somewhat uncertain on two things that I'd appreciate more feedback on:
1. The optional temporary local overrides. Perhaps this is superfluous and we can simply make the transition without the override?
2. If this set of parameters seems to be large enough to allow application developers to create the chains they want but not so large as to be needlessly complex.
This ADR restores a variation of the old Request for Comments documentation
that we previously used. The proposal differs from the original formulation,
and does not replace ADRs.
Per conversations earlier today, we'll consider all proposed implementation changes part of the ADR process rather than the RFC process (which will remain, for now, on the spec; this may get incorporated instead into the burgeoning "CIPS" process).
This change renames RFC 1 to ADR 66, leaving space for the not-yet-merged ADR 65.
## Description
This pr adds missing adr numbers based on what is in #2313
This pr adds empty templates that should later be filled when the time comes to do the implementation.
there are still missing numbers, we can either fill them in when we write more ADRs or not backfill numbers and only go forwards.
Closes: #2313
## Description
This adr is meant to weight the pros and cons of gRPC and JSON-RPC. It is fairly incomplete on the JSON-RPC side.
EDIT: Thank you to erik on filling out the pros and cons!!
Work Towards: #3367
* adr: crypto encoding for proto work
- this adr is meant to help with deciding on how to move forward with keys in tendermint.
* minor change
* fix gomod
* add a third option
* fix spelling
* add first part of descision
* breakdown keys and where they are used
* add some wording
* minor wording fix
* question
* change proto messages
* minor update
* undo go.mod changes
* add a few things based on comemnts
* push, push it real good
* minor explanation on interface type
* touch up
* adr: light client implementation
Closes#2133
* note on chain IDs
* explain why witnesses are required
* if chain forks maliciously, chain ID stays the same
* add a note about min witnesses while cross-checking
* Separate ADR Tendermint Mode from ADR-051
* Update docs/architecture/adr-052-tendermint-mode.md
Co-Authored-By: Anton Kaliaev <anton.kalyaev@gmail.com>
* Apply suggestions from code review
Co-Authored-By: Marko <marbar3778@yahoo.com>
* Apply suggestions from code review
Co-Authored-By: Marko <marbar3778@yahoo.com>
* remove line of mode info of rpc
* Add link to ADR table of contents
Co-authored-by: Anton Kaliaev <anton.kalyaev@gmail.com>
Co-authored-by: Marko <marbar3778@yahoo.com>
Fullnode mode : fullnode mode does not have any capability to participate on consensus
Validator mode : this mode is exactly same as existing state machine behavior. sync without voting on consensus, and participate consensus when fully synced
Seed mode : lightweight seed mode only for maintain an address book, p2p like TenderSeed
Separate ADR Tendermint Mode from ADR-051 #4262
* docs theme
* vuepress-theme-cosmos
* version bump
* changes to docs
* more code changes
* sidebar order fix
* moar changes
* fixed dev sessions title
* fixed dev sessions title, again
* specs should show up in sidebar
* contents cards
* version bump
* sidebar, rpc
* version bump
* custom footer and super naive search
* version
* minor change to vuepress
* move swagger file
* pre and post scripts
* build
* changed docs build process
* added deployment config
* updated versions file and added deployment filters
* ADR TOC in readme.md
* Added A TOC to the Readme.md of ADR Section
- Added table of contents to the Readme of the architecture section.
- Easier to traverse and when you know what is there.
- If the Adr's become viewable online it would help guide the user
Signed-off-by: Marko Baricevic <marbar3778@yahoo.com>
* add tm-cmn to subprojects
* normalize word
Thane Thomson
Sam Kleinman
M. J. Fromberger
William Banfield
Marko
Aleksandr Bezobchuk
Callum Waters
Tess Rinearson
Erik Grinaker
John Adler
Anton Kaliaev
mergify[bot]
dongsamb
Denis Fadeev
Zach Ramsay
Ethan Buchman
Liamsi
Adrian Brink
Ethan Frey