Composable Architecture Guidelines

[ZaradarBH]

Problem definition We need to establish a "composable architecture" for the L1 team that will outline our engineering guidelines, branching strategies, release versioning schemas, etc. I propose that we shoot for a minimalistic version of something like this: https://github.com/dfds/cag

Feature specification

• [ ] Coordinate and execute team session on "composable architecture & platform-as-a-product"
• [ ] Establish L1 taxonomy based on @ https://github.com/dfds/cag/blob/master/docs/taxonomy/TAXONOMY.md
• [ ] Establish baseline "release versioning scheme" to govern our SemVer increments. (see comments below for initial draft)
• [ ] Document our canonical branches and branching strategy based on @ https://dev-cafe.github.io/branching-model/
• [ ] Establish v0.1 engineering guidelines loosely based on @ https://go.dev/talks/2012/splash.article
• [ ] Discuss adopting EditorConfig as a means of enforcing our "coding standard and naming schemes" across multiple IDEs @ https://editorconfig.org/
• [ ] Identify "scope-of-work" and create issues for the above.

Additional context .

Acceptance criteria

• [ ] Establish consensus on the L1 teams CAG
• [ ] Publish CAG v1.0

[ZaradarBH]

Initial draft by @inon-man & supported by @ZaradarBH

major hard-fork breaking changes in API (REST, gRPC, CLI) epic minor soft-fork incl. upgrade feature upgrade (e.g. burn split tax) cosmos-sdk upgrade without breaking API change patch improvements, features, bug fixes

[nghuyenthevinh2000]

conventional commit types: https://github.com/conventional-changelog/commitlint/tree/master/%40commitlint/config-conventional

[ 'build', 'chore', 'ci', 'docs', 'feat', 'fix', 'perf', 'refactor', 'revert', 'style', 'test' ]

[inon-man]

Closing outdate issues.