From 6ccc79e5b76f090f8a7aac3b304f1b630384d27a Mon Sep 17 00:00:00 2001 From: bizk Date: Wed, 31 May 2023 17:12:42 -0300 Subject: [PATCH 1/2] Added adr md documentation --- .../adr-066-rosetta-standalone.md | 67 +++++++++++++++++++ 1 file changed, 67 insertions(+) create mode 100644 docs/architecture/adr-066-rosetta-standalone.md diff --git a/docs/architecture/adr-066-rosetta-standalone.md b/docs/architecture/adr-066-rosetta-standalone.md new file mode 100644 index 00000000000..efe5af568cc --- /dev/null +++ b/docs/architecture/adr-066-rosetta-standalone.md @@ -0,0 +1,67 @@ +# ADR 606: Rosetta standalone + +## Changelog + +* May 31, 2023: Initial draft (@Bizk) + +## Status + +DRAFT + +## Abstract + +Rosetta implementation runs on top of Cosmos SDK. The tool should rely on stable cosmos-sdk. +releases and not experimental features in order to ensure usability and stability. +Having the tool inside the main cosmos-sdk repo may cause unrequired updates, and make the +tool maintenance more complicated. + +## Context + +In the current context; Rosetta is inside cosmos-sdk project due to easier maintainability. +This is a problem because as seen in some previous commits, it has suffered unrequired changes +like updates due to a refactor or a new experimental feature. Causing issues like missmatch +dependencies or unexpected behaviour that needs to be addressed down the line. + +Since Rosetta is a standalone tool that has been implemented using Cosmos-sdk, it should only +rely on top of the latest releases, instead of being affected by experimental features or +interfeering over the cosmos-sdk development. + +Decoupling Rosetta from the cosmos-sdk project is no only a good practice since it keeps the +scope well defined, but also it ensures better maintainability over time. + +## Alternatives + +The 2 altnernatives are: +- **Keep the Project inside Cosmos-sdk**: This might be easier to handle from a fully immersed position. + maintainer's point of view, who works on different aspects of cosmos-sdk and might want to try + features into Rosetta. +- **Move the project into another repo**: This approach intends to keep the scope well defined, + and to ensure maintainability and stability over time. + +## Decision + +We will move Rosetta into a standalone repo in order to keep the Scope well defined, a stable +versioning, and to ensure an easier and cleaner maintainability. + +We will also add and keep track of quality standards as tests and following cosmos-sdk releases. + +## Consequences + +The consequence will be a new repo that contains the rosetta tool implemented by cosmos. + +### Positive + +- Better scope. +- Easier miantainability and testing. +- Avoids unrequired changes. +- Easier to fork / contribute. + +### Negative + +- Adds one more repo to keep track of. +- More dificult to test experimental features from cosmos-sdk + +## Further Discussions + +- [Discussion on migrating Rosetta into a standalone repo](https://github.com/cosmos/cosmos-sdk/issues/16276) +- [Zondax plugin implementation Test](https://github.com/Zondax/cosmos-sdk/pull/653) \ No newline at end of file From 047e53c7989f0703cf8b6fff942581915af85508 Mon Sep 17 00:00:00 2001 From: bizk Date: Thu, 1 Jun 2023 12:22:14 -0300 Subject: [PATCH 2/2] Added adr ida comments --- docs/architecture/adr-066-rosetta-standalone.md | 14 +++++++------- 1 file changed, 7 insertions(+), 7 deletions(-) diff --git a/docs/architecture/adr-066-rosetta-standalone.md b/docs/architecture/adr-066-rosetta-standalone.md index efe5af568cc..d1333da9d7e 100644 --- a/docs/architecture/adr-066-rosetta-standalone.md +++ b/docs/architecture/adr-066-rosetta-standalone.md @@ -19,20 +19,20 @@ tool maintenance more complicated. In the current context; Rosetta is inside cosmos-sdk project due to easier maintainability. This is a problem because as seen in some previous commits, it has suffered unrequired changes -like updates due to a refactor or a new experimental feature. Causing issues like missmatch -dependencies or unexpected behaviour that needs to be addressed down the line. +like updates due to a refactor or a new experimental feature. Such changes can cause mismatches +in dependencies, or unexpected behaviour that needs to be addressed down the line. -Since Rosetta is a standalone tool that has been implemented using Cosmos-sdk, it should only -rely on top of the latest releases, instead of being affected by experimental features or +Since Rosetta is a standalone tool that has been implemented using Cosmos-sdk, it should +rely only on each release, instead of being affected by experimental features or interfeering over the cosmos-sdk development. -Decoupling Rosetta from the cosmos-sdk project is no only a good practice since it keeps the +Decoupling Rosetta from the cosmos-sdk project is not only a good practice since it keeps the scope well defined, but also it ensures better maintainability over time. ## Alternatives The 2 altnernatives are: -- **Keep the Project inside Cosmos-sdk**: This might be easier to handle from a fully immersed position. +- **Keep Project inside Cosmos-sdk**: This might be easier to handle from a fully immersed position. maintainer's point of view, who works on different aspects of cosmos-sdk and might want to try features into Rosetta. - **Move the project into another repo**: This approach intends to keep the scope well defined, @@ -43,7 +43,7 @@ The 2 altnernatives are: We will move Rosetta into a standalone repo in order to keep the Scope well defined, a stable versioning, and to ensure an easier and cleaner maintainability. -We will also add and keep track of quality standards as tests and following cosmos-sdk releases. +We will also add and keep track of quality standards as tests and follow cosmos-sdk releases. ## Consequences