From acb3d747609213d1ebce4236d194580c47534468 Mon Sep 17 00:00:00 2001 From: Alex | Interchain Labs Date: Thu, 8 May 2025 15:44:28 -0400 Subject: [PATCH] chore: clean repo (#24723) --- .github/ISSUE_TEMPLATE/bug-report.md | 30 -- .github/ISSUE_TEMPLATE/bug-report.yml | 49 --- .github/ISSUE_TEMPLATE/documentation.yml | 18 - .github/ISSUE_TEMPLATE/epics.md | 31 -- .github/ISSUE_TEMPLATE/epics.yml | 43 --- .github/ISSUE_TEMPLATE/feature-request.md | 28 -- .github/ISSUE_TEMPLATE/feature-request.yml | 41 -- .../module-readiness-checklist.md | 40 -- .github/ISSUE_TEMPLATE/qa.md | 87 ----- .github/PULL_REQUEST_TEMPLATE.md | 32 -- CODE_OF_CONDUCT.md | 46 --- CODING_GUIDELINES.md | 152 -------- CONTRIBUTING.md | 355 ------------------ README.md | 5 - RELEASE_PROCESS.md | 248 ------------ ROADMAP.md | 270 ------------- cliff.toml | 128 ------- docs/README.md | 2 - 18 files changed, 1605 deletions(-) delete mode 100644 .github/ISSUE_TEMPLATE/bug-report.md delete mode 100644 .github/ISSUE_TEMPLATE/bug-report.yml delete mode 100644 .github/ISSUE_TEMPLATE/documentation.yml delete mode 100644 .github/ISSUE_TEMPLATE/epics.md delete mode 100644 .github/ISSUE_TEMPLATE/epics.yml delete mode 100644 .github/ISSUE_TEMPLATE/feature-request.md delete mode 100644 .github/ISSUE_TEMPLATE/feature-request.yml delete mode 100644 .github/ISSUE_TEMPLATE/module-readiness-checklist.md delete mode 100644 .github/ISSUE_TEMPLATE/qa.md delete mode 100644 CODE_OF_CONDUCT.md delete mode 100644 CODING_GUIDELINES.md delete mode 100644 CONTRIBUTING.md delete mode 100644 RELEASE_PROCESS.md delete mode 100644 ROADMAP.md delete mode 100644 cliff.toml diff --git a/.github/ISSUE_TEMPLATE/bug-report.md b/.github/ISSUE_TEMPLATE/bug-report.md deleted file mode 100644 index cc2ac6375e..0000000000 --- a/.github/ISSUE_TEMPLATE/bug-report.md +++ /dev/null @@ -1,30 +0,0 @@ ---- -name: Bug Report -about: Create a report to help us squash bugs! -title: "[Bug]: " -labels: "T:Bug" ---- - - - - - -## Summary of Bug - - - -## Version - - - -## Steps to Reproduce - - diff --git a/.github/ISSUE_TEMPLATE/bug-report.yml b/.github/ISSUE_TEMPLATE/bug-report.yml deleted file mode 100644 index e33d7aafc0..0000000000 --- a/.github/ISSUE_TEMPLATE/bug-report.yml +++ /dev/null @@ -1,49 +0,0 @@ -name: 🐛 Bug report -description: Create a report to help us squash bugs! -title: "[Bug]: " -labels: ["T:Bug"] -body: - - type: markdown - attributes: - value: | - Thanks for taking the time to fill out this bug report! - Before smashing the submit button please review the template. - - - type: checkboxes - attributes: - label: Is there an existing issue for this? - description: Please search existing issues to avoid creating duplicates. - options: - - label: I have searched the existing issues - required: true - - - type: markdown - attributes: - value: | - IMPORTANT: Prior to opening a bug report, check if it affects one of the core modules - and if its eligible for a bug bounty on `SECURITY.md`. Bugs that are not submitted - through the appropriate channels won't receive any bounty. - - type: textarea - id: what-happened - attributes: - label: What happened? - description: Also tell us, what did you expect to happen? - placeholder: Tell us what you see! - value: "A bug happened!" - validations: - required: true - - type: input - attributes: - label: Cosmos SDK Version - description: If applicable, specify the version you're using - placeholder: 0.46, 0.47, main, etc. - validations: - required: true - - type: textarea - id: reproduce - attributes: - label: How to reproduce? - description: If applicable could you describe how we could reproduce the bug - placeholder: Tell us what how to reproduce the bug! - validations: - required: false diff --git a/.github/ISSUE_TEMPLATE/documentation.yml b/.github/ISSUE_TEMPLATE/documentation.yml deleted file mode 100644 index 5e1c3423bb..0000000000 --- a/.github/ISSUE_TEMPLATE/documentation.yml +++ /dev/null @@ -1,18 +0,0 @@ -name: Documentation Request -description: Create an issue for missing or incorrect documentation -title: "[Documentation]: " -labels: ["T:Docs"] -body: - - type: markdown - attributes: - value: | - ✰ Thanks for opening an issue! ✰ - Tell us where what you would like to see get added to the documentation or if there is an error in the documentation? - - - type: textarea - id: what-happened - attributes: - label: Summary - placeholder: Description of what you would like to see - validations: - required: true diff --git a/.github/ISSUE_TEMPLATE/epics.md b/.github/ISSUE_TEMPLATE/epics.md deleted file mode 100644 index 70e4ab5e00..0000000000 --- a/.github/ISSUE_TEMPLATE/epics.md +++ /dev/null @@ -1,31 +0,0 @@ ---- -name: Epic -about: Create an epic/user -title: "[Epic]: " -labels: T:Epic ---- - - - -## Summary - - - -## Problem Definition - - - -## Work Breakdown - - diff --git a/.github/ISSUE_TEMPLATE/epics.yml b/.github/ISSUE_TEMPLATE/epics.yml deleted file mode 100644 index a8fb183788..0000000000 --- a/.github/ISSUE_TEMPLATE/epics.yml +++ /dev/null @@ -1,43 +0,0 @@ - -name: Epic -description: Create an epic/user -title: "[Epic]: " -labels: ["T:Epic"] -body: - - type: markdown - attributes: - value: | - Thanks for opening this issue, this template is meant for long lived work scopes, if this is what you're looking for please continue - - - type: textarea - id: summary - attributes: - label: Summary - description: | - What are the user needs? - How could this solution fix the user facing problem? - placeholder: Short, concise description of the proposed feature/changes to the repository - validations: - required: true - - type: textarea - id: problem - attributes: - label: Problem Definition - description: | - Why do we need this feature? - What problems may be addressed by introducing this feature? - What benefits does the SDK stand to gain by including this feature? - Are there any disadvantages of including this feature? - placeholder: Description of the issue being faced - validations: - required: true - - type: textarea - id: work - attributes: - label: Work Breakdown - description: | - Break the work into many bullet points that will later be turned into issues that can be assigned to developers to work on - This work may been to be broken up into phases of work in order to better organize when and how things get done. - placeholder: Description of the steps needed to deliver this feature - validations: - required: true diff --git a/.github/ISSUE_TEMPLATE/feature-request.md b/.github/ISSUE_TEMPLATE/feature-request.md deleted file mode 100644 index f46e9f1394..0000000000 --- a/.github/ISSUE_TEMPLATE/feature-request.md +++ /dev/null @@ -1,28 +0,0 @@ ---- -name: Feature Request -about: Create a proposal to request a feature -title: "[Feature]: " -labels: T:feature-request ---- - - - -## Summary - - - -## Problem Definition - - - -## Proposal - - diff --git a/.github/ISSUE_TEMPLATE/feature-request.yml b/.github/ISSUE_TEMPLATE/feature-request.yml deleted file mode 100644 index b3d3fc479f..0000000000 --- a/.github/ISSUE_TEMPLATE/feature-request.yml +++ /dev/null @@ -1,41 +0,0 @@ -name: Feature Request -description: Create a proposal to request a feature -title: "[Feature]: " -labels: ["T:feature-request"] -body: - - type: markdown - attributes: - value: | - ✰ Thanks for opening an issue! ✰ - - type: textarea - id: summary - attributes: - label: Summary - description: | - What are the user needs? - How could this solution fix the user facing problem? - placeholder: Short, concise description of the proposed feature/changes to the repository - validations: - required: true - - type: textarea - id: problem - attributes: - label: Problem Definition - description: | - If applicable please answer the below questions - Why do we need this feature? - What problems may be addressed by introducing this feature? - What benefits does the SDK stand to gain by including this feature? - Are there any disadvantages of including this feature? - placeholder: Description of the issue being faced - validations: - required: false - - type: textarea - id: proposal - attributes: - label: Proposed Feature - description: | - Description of the proposed features or changes to an existing feature to meet your needs - placeholder: Description of the proposed feature(s) - validations: - required: true diff --git a/.github/ISSUE_TEMPLATE/module-readiness-checklist.md b/.github/ISSUE_TEMPLATE/module-readiness-checklist.md deleted file mode 100644 index 7892e356bc..0000000000 --- a/.github/ISSUE_TEMPLATE/module-readiness-checklist.md +++ /dev/null @@ -1,40 +0,0 @@ ---- -name: Module Readiness Checklist -about: Pre-flight checklist that modules must pass in order to be included in a release of the Cosmos SDK -labels: 'module-readiness-checklist' ---- - -## x/{MODULE_NAME} Module Readiness Checklist - -This checklist is to be used for tracking the final internal audit of new Cosmos SDK modules prior to inclusion in a published release. - -### Release Candidate Checklist - -The following checklist should be gone through once the module has been fully implemented. This audit should be performed directly on `main`, or preferably on a `alpha` or `beta` release tag that includes the module. - -The module **should not** be included in any Release Candidate tag until it has passed this checklist. - -- [ ] API audit (at least 1 person) (@assignee) - - [ ] Are Msg and Query methods and types well-named and organized? - - [ ] Is everything well documented (inline godoc as well as the spec [README.md](https://github.com/cosmos/cosmos-sdk/blob/main/docs/spec/README.md) in module directory) -- [ ] State machine audit (at least 2 people) (@assignee1, @assignee2) - - [ ] Read through MsgServer code and verify correctness upon visual inspection - - [ ] Ensure all state machine code which could be confusing is properly commented - - [ ] Make sure state machine logic matches Msg method documentation - - [ ] Ensure that all state machine edge cases are covered with tests and that test coverage is sufficient (at least 90% coverage on module code) - - [ ] Assess potential threats for each method including spam attacks and ensure that threats have been addressed sufficiently. This should be done by writing up threat assessment for each method - - [ ] Assess potential risks of any new third party dependencies and decide whether a dependency audit is needed -- [ ] Completeness audit, fully implemented with tests (at least 1 person) (@assignee) - - [ ] Genesis import and export of all state - - [ ] Query services - - [ ] CLI methods - - [ ] All necessary migration scripts are present (if this is an upgrade of existing module) - -### Published Release Checklist - -After the above checks have been audited and the module is included in a tagged Release Candidate, the following additional checklist should be undertaken for live testing, and potentially a 3rd party audit (if deemed necessary): - -- [ ] Testnet / devnet testing (2-3 people) (@assignee1, @assignee2, @assignee3) - - [ ] All Msg methods have been tested especially in light of any potential threats identified - - [ ] Genesis import and export has been tested -- [ ] Nice to have (and needed in some cases if threats could be high): Official 3rd party audit diff --git a/.github/ISSUE_TEMPLATE/qa.md b/.github/ISSUE_TEMPLATE/qa.md deleted file mode 100644 index 953ee48032..0000000000 --- a/.github/ISSUE_TEMPLATE/qa.md +++ /dev/null @@ -1,87 +0,0 @@ - - -## Summary - - - -## Major Changes - - - -## Gotchas - - - -## QA Breakdown - -* Audit - * [ ] Audit BaseApp - * [ ] Audit Types - * [ ] Audit x/auth - * [ ] Audit x/authz - * [ ] Audit x/bank - * [ ] Audit x/circuit - * [ ] Audit x/consensus - * [ ] Audit x/distribution - * [ ] Audit x/evidence - * [ ] Audit x/epochs - * [ ] Audit x/feegrant - * [ ] Audit x/genutil - * [ ] Audit x/gov - * [ ] Audit x/group - * [ ] Audit x/mint - * [ ] Audit x/nft - * [ ] Audit x/protocolpool - * [ ] Audit x/slashing - * [ ] Audit x/staking - * [ ] Audit x/tx - * [ ] Audit x/upgrade - * [ ] Audit client - * [ ] Audit server - * [ ] Audit store - * [ ] Audit runtime - * [ ] Audit simapp -* [ ] Release alpha -* [ ] Cosmos-SDK testnet -* [ ] Public testnet (IBC, WASM, SDK) -* [ ] Upgrade a chain with data from vX -* Release documentation - * [ ] Audit UPGRADING.md - * [ ] Update all codeblock to the appropriate version number - - -### Audit checklist - -* please copy to a markdown to follow while you walk through the code -* 2 people should be assigned to each section - -* [ ] API audit - * spec audit: check if the spec is complete. - * Are Msg and Query methods and types well-named and organized? - * Is everything well documented (inline godoc as well as package [`README.md`](https://docs.cosmos.network/main/spec/SPEC_MODULE#common-layout) in module directory) - * check the proto definition - make sure everything is in accordance to ADR-30 (at least 1 person, TODO assignee) - * Check new fields and endpoints have the `Since: cosmos-sdk X` comment -* [ ] Completeness audit, fully implemented with tests - * [ ] Genesis import and export of all state - * [ ] Query services - * [ ] CLI methods - * [ ] All necessary migration scripts are present (if this is an upgrade of existing module) -* [ ] State machine audit - * [ ] Read through MsgServer code and verify correctness upon visual inspection - * [ ] Ensure all state machine code which could be confusing is properly commented - * [ ] Make sure state machine logic matches Msg method documentation - * [ ] Ensure that all state machine edge cases are covered with tests and that test coverage is sufficient (at least 90% coverage on module code) - * [ ] Assess potential threats for each method including spam attacks and ensure that threats have been addressed sufficiently. This should be done by writing up threat assessment for each method. Specifically we should be paying attention to: - * [ ] algorithmic complexity and places this could be exploited (ex. nested `for` loops) - * [ ] charging gas complex computation (ex. `for` loops) - * [ ] storage is safe (we don't pollute the state). - * [ ] Assess potential risks of any new third party dependencies and decide whether a dependency audit is needed - * [ ] Check correctness of simulation implementation if any -* [ ] Audit Changelog against commit log, ensuring all breaking changes, bug fixes, and improvements are properly documented. - -If any changes are needed, please make them against main and backport them to release/vX.X.x diff --git a/.github/PULL_REQUEST_TEMPLATE.md b/.github/PULL_REQUEST_TEMPLATE.md index 2598179b73..afe2b942db 100644 --- a/.github/PULL_REQUEST_TEMPLATE.md +++ b/.github/PULL_REQUEST_TEMPLATE.md @@ -4,35 +4,3 @@ Closes: #XXXX - ---- - -## Author Checklist - -*All items are required. Please add a note to the item if the item is not applicable and -please add links to any relevant follow up issues. Your PR will not be merged unless you satisfy -all of these items.* - -I have... - -* [ ] included the correct [type prefix](https://github.com/commitizen/conventional-commit-types/blob/v3.0.0/index.json) in the PR title, you can find examples of the prefixes below: - -* [ ] confirmed `!` in the type prefix if API or client breaking change -* [ ] targeted the correct branch (see [PR Targeting](https://github.com/cosmos/cosmos-sdk/blob/main/CONTRIBUTING.md#pr-targeting)) -* [ ] provided a link to the relevant issue or specification -* [ ] reviewed "Files changed" and left comments if necessary -* [ ] included the necessary unit and integration [tests](https://github.com/cosmos/cosmos-sdk/blob/main/CONTRIBUTING.md#testing) -* [ ] added a changelog entry to `CHANGELOG.md` -* [ ] updated the relevant documentation or specification, including comments for [documenting Go code](https://blog.golang.org/godoc) -* [ ] confirmed all CI checks have passed - diff --git a/CODE_OF_CONDUCT.md b/CODE_OF_CONDUCT.md deleted file mode 100644 index c9f9cc2405..0000000000 --- a/CODE_OF_CONDUCT.md +++ /dev/null @@ -1,46 +0,0 @@ -# Contributor Covenant Code of Conduct - -## Our Pledge - -In the interest of fostering an open and welcoming environment, we as contributors and maintainers pledge to making participation in our project and our community a harassment-free experience for everyone, regardless of age, body size, disability, ethnicity, gender identity and expression, level of experience, nationality, personal appearance, race, religion, or sexual identity and orientation. - -## Our Standards - -Examples of behavior that contributes to creating a positive environment include: - -* Using welcoming and inclusive language -* Being respectful of differing viewpoints and experiences -* Gracefully accepting constructive criticism -* Focusing on what is best for the community -* Showing empathy towards other community members - -Examples of unacceptable behavior by participants include: - -* The use of sexualized language or imagery and unwelcome sexual attention or advances -* Trolling, insulting/derogatory comments, and personal or political attacks -* Public or private harassment -* Publishing others' private information, such as a physical or electronic address, without explicit permission -* Other conduct which could reasonably be considered inappropriate in a professional setting - -## Our Responsibilities - -Project maintainers are responsible for clarifying the standards of acceptable behavior and are expected to take appropriate and fair corrective action in response to any instances of unacceptable behavior. - -Project maintainers have the right and responsibility to remove, edit, or reject comments, commits, code, wiki edits, issues, and other contributions that are not aligned to this Code of Conduct, or to ban temporarily or permanently any contributor for other behaviors that they deem inappropriate, threatening, offensive, or harmful. - -## Scope - -This Code of Conduct applies both within project spaces and in public spaces when an individual is representing the project or its community. Examples of representing a project or community include using an official project e-mail address, posting via an official social media account, or acting as an appointed representative at an online or offline event. Representation of a project may be further defined and clarified by project maintainers. - -## Enforcement - -Instances of abusive, harassing, or otherwise unacceptable behavior may be reported by contacting the project team at community@interchain.io. The project team will review and investigate all complaints, and will respond in a way that it deems appropriate to the circumstances. The project team is obligated to maintain confidentiality with regard to the reporter of an incident. Further details of specific enforcement policies may be posted separately. - -Project maintainers who do not follow or enforce the Code of Conduct in good faith may face temporary or permanent repercussions as determined by other members of the project's leadership. - -## Attribution - -This Code of Conduct is adapted from the [Contributor Covenant][homepage], version 1.4, available at [http://contributor-covenant.org/version/1/4][version] - -[homepage]: http://contributor-covenant.org -[version]: http://contributor-covenant.org/version/1/4/ diff --git a/CODING_GUIDELINES.md b/CODING_GUIDELINES.md deleted file mode 100644 index 8793b5e42b..0000000000 --- a/CODING_GUIDELINES.md +++ /dev/null @@ -1,152 +0,0 @@ -# Coding Guidelines - -This document is an extension to [CONTRIBUTING](./CONTRIBUTING.md) and provides more details about the coding guidelines and requirements. - -## API & Design - -* Code must be well structured: - * packages must have a limited responsibility (different concerns can go to different packages), - * types must be easy to compose, - * think about maintainbility and testability. -* "Depend upon abstractions, [not] concretions". -* Try to limit the number of methods you are exposing. It's easier to expose something later than to hide it. -* Take advantage of `internal` package concept. -* Follow agreed-upon design patterns and naming conventions. -* publicly-exposed functions are named logically, have forward-thinking arguments and return types. -* Avoid global variables and global configurators. -* Favor composable and extensible designs. -* Minimize code duplication. -* Limit third-party dependencies. - -Performance: - -* Avoid unnecessary operations or memory allocations. - -Security: - -* Pay proper attention to exploits involving: - * gas usage - * transaction verification and signatures - * malleability - * code must be always deterministic -* Thread safety. If some functionality is not thread-safe, or uses something that is not thread-safe, then clearly indicate the risk on each level. - -## Acceptance tests - -Start the design by defining Acceptance Tests. The purpose of Acceptance Testing is to -validate that the product being developed corresponds to the needs of the real users -and is ready for launch. Hence we often talk about **User Acceptance Test** (UAT). -It also gives a better understanding of the product and helps designing a right interface -and API. - -UAT should be revisited at each stage of the product development: - -![acceptance-tests.png](./docs/static/img/acceptance-tests.png) - -### Why Acceptance Testing - -* Automated acceptance tests catch serious problems that unit or component test suites could never catch. -* Automated acceptance tests deliver business value the users are expecting as they test user scenarios. -* Automated acceptance tests executed and passed on every build help improve the software delivery process. -* Testers, developers, and customers need to work closely to create suitable automated acceptance test suites. - -### How to define Acceptance Test - -The best way to define AT is by starting from the user stories and think about all positive and negative scenarios a user can perform. - -Product Developers should collaborate with stakeholders to define AT. Functional experts and business users are both needed for defining AT. - -A good pattern for defining AT is listing scenarios with [GIVEN-WHEN-THEN](https://martinfowler.com/bliki/GivenWhenThen.html) format where: - -* **GIVEN**: A set of initial circumstances (e.g. bank balance) -* **WHEN**: Some event happens (e.g. customer attempts a transfer) -* **THEN**: The expected result as per the defined behavior of the system - -In other words: we define a use case input, current state and the expected outcome. Example: - -> Feature: User trades stocks. -> Scenario: User requests a sell before close of trading -> -> Given I have 100 shares of MSFT stock -> And I have 150 shares of APPL stock -> And the time is before close of trading -> -> When I ask to sell 20 shares of MSFT stock -> -> Then I should have 80 shares of MSFT stock -> And I should have 150 shares of APPL stock -> And a sell order for 20 shares of MSFT stock should have been executed - -*Reference: [writing acceptance tests](https://openclassrooms.com/en/courses/4544611-write-agile-documentation-user-stories-acceptance-tests/4810081-writing-acceptance-tests)*. - -### How and where to add acceptance tests - -Acceptance tests are written in the Markdown format, using the scenario template described above, and be part of the specification (`xx_test.md` file in *spec* directory). Example: [`eco-credits/spec/06.test.md`](https://github.com/regen-network/regen-ledger/blob/7297783577e6cd102c5093365b573163680f36a1/x/ecocredit/spec/06_tests.md). - -Acceptance tests should be defined during the design phase or at an early stage of development. Moreover, they should be defined before writing a module architecture - it will clarify the purpose and usage of the software. -Automated tests should cover all acceptance tests scenarios. - -## Automated Tests - -Make sure your code is well tested: - -* Provide unit tests for every unit of your code if possible. Unit tests are expected to comprise 70%-80% of your tests. -* Describe the test scenarios you are implementing for integration tests. -* Create integration tests for queries and msgs. -* Use both test cases and property / fuzzy testing. We use the [rapid](pgregory.net/rapid) Go library for property-based and fuzzy testing. -* Do not decrease code test coverage. Explain in a PR if test coverage is decreased. - -We expect tests to use `require` or `assert` rather than `t.Skip` or `t.Fail`, -unless there is a reason to do otherwise. -When testing a function under a variety of different inputs, we prefer to use -[table driven tests](https://github.com/golang/go/wiki/TableDrivenTests). -Table driven test error messages should follow the following format -`, tc #, i #`. -`` is an optional short description of whats failing, `tc` is the -index within the test case table that is failing, and `i` is when there -is a loop, exactly which iteration of the loop failed. -The idea is you should be able to see the -error message and figure out exactly what failed. -Here is an example check: - -```go - -for tcIndex, tc := range cases { - - resp, err := doSomething() - require.NoError(err) - require.Equal(t, tc.expected, resp, "should correctly perform X") -``` - -## Quality Assurance - -We are forming a QA team that will support the core Cosmos SDK team and collaborators by: - -* Improving the Cosmos SDK QA Processes -* Improving automation in QA and testing -* Defining high-quality metrics -* Maintaining and improving testing frameworks (unit tests, integration tests, and functional tests) -* Defining test scenarios. -* Verifying user experience and defining a high quality. - * We want to have **acceptance tests**! Document and list acceptance lists that are implemented and identify acceptance tests that are still missing. - * Acceptance tests should be specified in `acceptance-tests` directory as Markdown files. -* Supporting other teams with testing frameworks, automation, and User Experience testing. -* Testing chain upgrades for every new breaking change. - * Defining automated tests that assure data integrity after an update. - -Desired outcomes: - -* QA team works with Development Team. -* QA is happening in parallel with Core Cosmos SDK development. -* Releases are more predictable. -* QA reports. Goal is to guide with new tasks and be one of the QA measures. - -As a developer, you must help the QA team by providing instructions for User Experience (UX) and functional testing. - -### QA Team to cross check Acceptance Tests - -Once the AT are defined, the QA team will have an overview of the behavior a user can expect and: - -* validate the user experience will be good -* validate the implementation conforms the acceptance tests -* by having a broader overview of the use cases, QA team should be able to define **test suites** and test data to efficiently automate Acceptance Tests and reuse the work. diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md deleted file mode 100644 index 288397d57d..0000000000 --- a/CONTRIBUTING.md +++ /dev/null @@ -1,355 +0,0 @@ -# Contributing - -* [Teams Dev Calls](#teams-dev-calls) -* [Architecture Decision Records (ADR)](#architecture-decision-records-adr) -* [Development Procedure](#development-procedure) - * [Testing](#testing) - * [Pull Requests](#pull-requests) - * [Pull Request Templates](#pull-request-templates) - * [Requesting Reviews](#requesting-reviews) - * [Updating Documentation](#updating-documentation) - * [RFC & ADR](#RFC & ADR) -* [Dependencies](#dependencies) - * [`go.work`](#gowork) - * [`go.mod`](#gomod) -* [Protobuf](#protobuf) -* [Branching Model and Release](#branching-model-and-release) - * [PR Targeting](#pr-targeting) -* [Code Owner Membership](#code-owner-membership) -* [Concept & Feature Approval Process](#concept--feature-approval-process) - * [Strategy Discovery](#strategy-discovery) - * [Concept Approval](#concept-approval) - * [Time Bound Period](#time-bound-period) - * [Approval Committee & Decision Making](#approval-committee--decision-making) - * [Committee Members](#committee-members) - * [Committee Criteria](#committee-criteria) - * [Implementation & Release Approval](#implementation--release-approval) - -Thank you for considering making contributions to the Cosmos SDK and related repositories! - -Contributing to this repo can mean many things, such as participating in -discussion or proposing code changes. To ensure a smooth workflow for all -contributors, the general procedure for contributing has been established: - -1. Start by browsing [new issues](https://github.com/cosmos/cosmos-sdk/issues) and [discussions](https://github.com/cosmos/cosmos-sdk/discussions). If you are looking for something interesting or if you have something in your mind, there is a chance it had been discussed. - * Looking for a good place to start contributing? How about checking out some [good first issues](https://github.com/cosmos/cosmos-sdk/issues?q=is%3Aopen+is%3Aissue+label%3A%22good+first+issue%22) or [bugs](https://github.com/cosmos/cosmos-sdk/issues?q=is%3Aopen+is%3Aissue+label%3A%22T%3A+Bug%22)? -2. Determine whether a GitHub issue or discussion is more appropriate for your needs: - 1. If want to propose something new that requires specification or an additional design, or you would like to change a process, start with a [new discussion](https://github.com/cosmos/cosmos-sdk/discussions/new). With discussions, we can better handle the design process using discussion threads. A discussion usually leads to one or more issues. - 2. If the issue you want addressed is a specific proposal or a bug, then open a [new issue](https://github.com/cosmos/cosmos-sdk/issues/new/choose). - 3. Review existing [issues](https://github.com/cosmos/cosmos-sdk/issues) to find an issue you'd like to help with. -3. Participate in thoughtful discussion on that issue. -4. If you would like to contribute: - 1. Ensure that the proposal has been accepted. - 2. Ensure that nobody else has already begun working on this issue. If they have, - make sure to contact them to collaborate. - 3. If nobody has been assigned for the issue and you would like to work on it, - make a comment on the issue to inform the community of your intentions - to begin work. -5. To submit your work as a contribution to the repository follow standard GitHub best practices. See [pull request guideline](#pull-requests) below. - -**Note:** For very small or blatantly obvious problems such as typos, you are -not required to an open issue to submit a PR, but be aware that for more complex -problems/features, if a PR is opened before an adequate design discussion has -taken place in a GitHub issue, that PR runs a high likelihood of being rejected. - -## Teams Dev Calls - -The Cosmos SDK has many stakeholders contributing and shaping the project. The Core SDK team is composed of Interchain GmbH and Regen Network Development developers. Any long-term contributors and additional maintainers from other projects are welcome. We use self-organizing principles to coordinate and collaborate across organizations in structured "EPIC" that focus on specific problem domains or architectural components of the Cosmos SDK. - -The developers work in sprints, which are available in a [GitHub Project](https://github.com/orgs/cosmos/projects/26/views/22). The current EPICs are pinned at the top of the [issues list](https://github.com/cosmos/cosmos-sdk/issues). - -The important development announcements are shared on [Discord](https://discord.com/invite/cosmosnetwork) in the `#dev-announcements` channel. - -To synchronize we have few major meetings: - -* Cosmos SDK Sprint Review on Monday and Thursday at 14:00 UTC (limited participation to core devs). -* Cosmos SDK Community Call on Thursday at 16:00 UTC. - -If you would like to join one of the community call, then please contact us on [Discord](https://discord.com/invite/cosmosnetwork) or reach out directly to Marko (@tac0turtle). - -## Architecture Decision Records (ADR) - -When proposing an architecture decision for the Cosmos SDK, please start by opening an [issue](https://github.com/cosmos/cosmos-sdk/issues/new/choose) or a [discussion](https://github.com/cosmos/cosmos-sdk/discussions/new) with a summary of the proposal. Once the proposal has been discussed and there is rough alignment on a high-level approach to the design, the [ADR creation process](https://github.com/cosmos/cosmos-sdk/blob/main/docs/architecture/PROCESS.md) can begin. We are following this process to ensure all involved parties are in agreement before any party begins coding the proposed implementation. If you would like to see examples of how these are written, please refer to the current [ADRs](https://github.com/cosmos/cosmos-sdk/tree/main/docs/architecture). - -## Development Procedure - -* The latest state of development is on `main`. -* `main` must never fail `make lint test test-race`. -* No `--force` onto `main` (except when reverting a broken commit, which should seldom happen). -* Create a branch to start work: - * Fork the repo (core developers must create a branch directly in the Cosmos SDK repo), - branch from the HEAD of `main`, make some commits, and submit a PR to `main`. - * For core developers working within the `cosmos-sdk` repo, follow branch name conventions to ensure a clear - ownership of branches: `{moniker}/{issue#}-branch-name`. - * See [Branching Model](#branching-model-and-release) for more details. -* Be sure to run `make format` before every commit. The easiest way - to do this is have your editor run it for you upon saving a file (most of the editors - will do it anyway using a pre-configured setup of the programming language mode). - Additionally, be sure that your code is lint compliant by running `make lint-fix`. - A convenience git `pre-commit` hook that runs the formatters automatically - before each commit is available in the `contrib/githooks/` directory. -* Follow the [CODING GUIDELINES](CODING_GUIDELINES.md), which defines criteria for designing and coding a software. - -Code is merged into main through pull request procedure. - -### Testing - -Tests can be executed by running `make test` at the top level of the Cosmos SDK repository. - -### Pull Requests - -Before submitting a pull request: - -* merge the latest main `git merge origin/main`, -* run `make lint test` to ensure that all checks and tests pass. - -Then: - -1. If you have something to show, **start with a `Draft` PR**. It's good to have early validation of your work and we highly recommend this practice. A Draft PR also indicates to the community that the work is in progress. - Draft PRs also helps the core team provide early feedback and ensure the work is in the right direction. -2. When the code is complete, change your PR from `Draft` to `Ready for Review`. -3. Go through the actions for each checkbox present in the PR template description. The PR actions are automatically provided for each new PR. -4. Be sure to include a relevant changelog entry in the `Unreleased` section of `CHANGELOG.md` (see file for log format). The entry should be on top of all others changes in the section. - -PRs must have a category prefix that is based on the type of changes being made (for example, `fix`, `feat`, -`refactor`, `docs`, and so on). The *type* must be included in the PR title as a prefix (for example, -`fix: `). This convention ensures that all changes that are committed to the base branch follow the -[Conventional Commits](https://www.conventionalcommits.org/en/v1.0.0/) specification. -Additionally, each PR should only address a single issue. - -Pull requests are merged automatically using [`A:automerge` action](https://docs.mergify.com/workflow/automerge/). - -NOTE: when merging, GitHub will squash commits and rebase on top of the main. - -### Pull Request Templates - -There are three PR templates. The [default template](./.github/PULL_REQUEST_TEMPLATE.md) is for types `fix`, `feat`, and `refactor`. We also have a [docs template](./.github/PULL_REQUEST_TEMPLATE/docs.md) for documentation changes and an [other template](./.github/PULL_REQUEST_TEMPLATE/other.md) for changes that do not affect production code. When previewing a PR before it has been opened, you can change the template by adding one of the following parameters to the url: - -* `template=docs.md` -* `template=other.md` - -### Requesting Reviews - -In order to accommodate the review process, the author of the PR must complete the author checklist -(from the pull request template) -to the best of their abilities before marking the PR as "Ready for Review". If you would like to -receive early feedback on the PR, open the PR as a "Draft" and leave a comment in the PR indicating -that you would like early feedback and tagging whoever you would like to receive feedback from. - -Codeowners are marked automatically as the reviewers. - -All PRs require at least two review approvals before they can be merged (one review might be acceptable in -the case of minor changes to [docs](./.github/PULL_REQUEST_TEMPLATE/docs.md) or [other](./.github/PULL_REQUEST_TEMPLATE/other.md) changes that do not affect production code). Each PR template has a reviewers checklist that must be completed before the PR can be merged. Each reviewer is responsible -for all checked items unless they have indicated otherwise by leaving their handle next to specific -items. In addition, use the following review explanations: - -* `LGTM` without an explicit approval means that the changes look good, but you haven't thoroughly reviewed the reviewer checklist items. -* `Approval` means that you have completed some or all of the reviewer checklist items. If you only reviewed selected items, you must add your handle next to the items that you have reviewed. In addition, follow these guidelines: - * You must also think through anything which ought to be included but is not - * You must think through whether any added code could be partially combined (DRYed) with existing code - * You must think through any potential security issues or incentive-compatibility flaws introduced by the changes - * Naming must be consistent with conventions and the rest of the codebase - * Code must live in a reasonable location, considering dependency structures (for example, not importing testing modules in production code, or including example code modules in production code). - * If you approve the PR, you are responsible for any issues mentioned here and any issues that should have been addressed after thoroughly reviewing the reviewer checklist items in the pull request template. -* If you sat down with the PR submitter and did a pairing review, add this information in the `Approval` or your PR comments. -* If you are only making "surface level" reviews, submit notes as a `comment` review. - -### Updating Documentation - -If you open a PR on the Cosmos SDK, it is mandatory to update the relevant documentation in `/docs`. - -* If your change relates to the core SDK (baseapp, store, ...), be sure to update the content in `docs/basics/`, `docs/core/` and/or `docs/building-modules/` folders. -* If your changes relate to the core of the CLI (not specifically to module's CLI/Rest), then modify the content in the `docs/run-node/` folder. -* If your changes relate to a module, then be sure to update the module's spec in `x/{moduleName}/README.md`. - -When writing documentation, follow the [Documentation Writing Guidelines](./docs/DOC_WRITING_GUIDELINES.md). - -### RFC & ADR - -Within the Cosmos SDK we have two forms of documenting decisions, Request For Comment (RFC) & Architecture Design Record (ADR). They perform two different functions. The process for assessing if something needs an RFC is located in the respective folders: - -* [RFC Process](./docs/rfc/process.md) -* [ADR Process](./docs/adr/process.md) - - -## Dependencies - -We use [Go Modules](https://github.com/golang/go/wiki/Modules) to manage -dependency versions. - -The main branch of every Cosmos repository should just build with `go get`, -which means they should be kept up-to-date with their dependencies, so we can -get away with telling people they can just `go get` our software. - -Since some dependencies are not under our control, a third party may break our -build, in which case we can fall back on `go mod tidy -v`. - -### `go.mod` - -When extracting a package to its own go modules, some extra steps are required, for keeping our CI checks and Dev UX: - -* Add a CHANGELOG.md / README.md under the new package folder -* Add the package in [`labeler.yml`](./.github/labeler.yml) -* Add weekly dependabot checks (see [dependabot.yml](./.github/dependabot.yml)) -* Add tests to github workflow [test.yml](.github/workflows/test.yml) (under submodules) -* (optional) Configure a `cosmossdk.io` vanity url by submitting a PR to [cosmos/vanity](https://github.com/cosmos/vanity). - -## Protobuf - -We use [Protocol Buffers](https://developers.google.com/protocol-buffers) along with [gogoproto](https://github.com/cosmos/gogoproto) to generate code for use in Cosmos SDK. - -For deterministic behavior around Protobuf tooling, everything is containerized using Docker. Make sure to have Docker installed on your machine, or head to [Docker's website](https://docs.docker.com/get-docker/) to install it. - -For formatting code in `.proto` files, you can run `make proto-format` command. - -For linting and checking breaking changes, we use [buf](https://buf.build/). You can use the commands `make proto-lint` and `make proto-check-breaking` to respectively lint your proto files and check for breaking changes. - -To generate the protobuf stubs, you can run `make proto-gen`. - -We also added the `make proto-all` command to run all the above commands sequentially. - -In order for imports to properly compile in your IDE, you may need to manually set your protobuf path in your IDE's workspace settings/config. - -For example, in vscode your `.vscode/settings.json` should look like: - -```json -{ - "protoc": { - "options": [ - "--proto_path=${workspaceRoot}/proto", - ] - } -} -``` - -## Branching Model and Release - -User-facing repos should adhere to the trunk based development branching model: https://trunkbaseddevelopment.com. User branches should start with a user name, example: `{moniker}/{issue#}-branch-name`. - -The Cosmos SDK repository is a [multi Go module](https://github.com/golang/go/wiki/Modules#is-it-possible-to-add-a-module-to-a-multi-module-repository) repository. It means that we have more than one Go module in a single repository. - -The Cosmos SDK utilizes [semantic versioning](https://semver.org/). - -### PR Targeting - -Ensure that you base and target your PR on the `main` branch. - -All feature additions and all bug fixes must be targeted against `main`. Exception is for bug fixes which are only related to a released version. In that case, the related bug fix PRs must target against the release branch. - -If needed, we backport a commit from `main` to a release branch (excluding consensus breaking feature, API breaking and similar). - -## Code Owner Membership - -In the ethos of open-source projects, and out of necessity to keep the code -alive, the core contributor team will strive to permit special repo privileges -to developers who show an aptitude towards developing with this code base. - -Several different kinds of privileges may be granted however most common -privileges to be granted are merge rights to either part of, or the entirety of the -code base (through the GitHub `CODEOWNERS` file). The on-boarding process for -new code owners is as follows: On a bi-monthly basis (or more frequently if -agreeable) all the existing code owners will privately convene to discuss -potential new candidates as well as the potential for existing code-owners to -exit or "pass on the torch". This private meeting is to be a held as a -phone/video meeting. - -Subsequently after the meeting, and pending final approval from the ICF, -one of the existing code owners should open a PR modifying the `CODEOWNERS` file. -The other code owners should then all approve this PR to publicly display their support. - -Only if unanimous consensus is reached among all the existing code-owners will -an invitation be extended to a new potential-member. Likewise, when an existing -member is suggested to be removed/or have their privileges reduced, the member -in question must agree to the decision for their removal or else no action -should be taken. If however, a code-owner is demonstrably shown to intentionally -have had acted maliciously or grossly negligent, code-owner privileges may be -stripped with no prior warning or consent from the member in question. - -Other potential removal criteria: - -* Missing 3 scheduled meetings results in ICF evaluating whether the member should be - removed / replaced -* Violation of Code of Conduct - -Earning this privilege should be considered to be no small feat and is by no -means guaranteed by any quantifiable metric. Serving as a code owner is a symbol of great trust from -the community of this project. - -## Concept & Feature Approval Process - -The process for how Cosmos SDK maintainers take features and ADRs from concept to release -is broken up into three distinct stages: **Strategy Discovery**, **Concept Approval**, and -**Implementation & Release Approval** - -### Strategy Discovery - -* Develop long term priorities, strategy and roadmap for the Cosmos SDK -* Release committee not yet defined as there is already a roadmap that can be used for the time being - -### Concept Approval - -* Architecture Decision Records (ADRs) may be proposed by any contributors or maintainers of the Cosmos SDK, - and should follow the guidelines outlined in the - [ADR Creation Process](https://github.com/cosmos/cosmos-sdk/blob/main/docs/architecture/PROCESS.md) -* After proposal, a time bound period for Request for Comment (RFC) on ADRs commences -* ADRs are intended to be iterative, and may be merged into `main` while still in a `Proposed` status - -#### Time Bound Period - -* Once a PR for an ADR is opened, reviewers are expected to perform a first review within 1 week of pull request being open -* Time bound period for individual ADR Pull Requests to be merged should not exceed 2 weeks -* Total time bound period for an ADR to reach a decision (`ABANDONED | ACCEPTED | REJECTED`) should not exceed 4 weeks - -If an individual Pull Request for an ADR needs more time than 2 weeks to reach resolution, it should be merged -in current state (`Draft` or `Proposed`), with its contents updated to summarize -the current state of its discussion. - -If an ADR is taking longer than 4 weeks to reach a final conclusion, the **Concept Approval Committee** -should convene to rectify the situation by either: - -* unanimously setting a new time bound period for this ADR -* making changes to the Concept Approval Process (as outlined here) -* making changes to the members of the Concept Approval Committee - -#### Approval Committee & Decision Making - -In absence of general consensus, decision making requires 1/2 vote from the two members -of the **Concept Approval Committee**. - -#### Committee Members - -* Core Members: **Aaron** (Regen), **Bez** (IG) - -#### Committee Criteria - -Members must: - -* Participate in all or almost all ADR discussions, both on GitHub as well as in bi-weekly Architecture Review - meetings -* Be active contributors to the Cosmos SDK, and furthermore should be continuously making substantial contributions - to the project's codebase, review process, documentation and ADRs -* Have stake in the Cosmos SDK project, represented by: - * Being a client / user of the Comsos SDK - * "[giving back](https://www.debian.org/social_contract)" to the software -* Delegate representation in case of vacation or absence - -Code owners need to maintain participation in the process, ideally as members of **Concept Approval Committee** -members, but at the very least as active participants in ADR discussions - -Removal criteria: - -* Missing 3 meetings results in ICF evaluating whether the member should be removed / replaced -* Violation of Code of Conduct - -### Implementation & Release Approval - -The following process should be adhered to both for implementation PRs corresponding to ADRs, as -well as for PRs made as part of a release process: - -* Code reviewers should ensure the PR does exactly what the ADR said it should -* Code reviewers should have more senior engineering capability -* 1/2 approval is required from the **primary repo maintainers** in `CODEOWNERS` - -**Note**: For any major release series denoted as a "Stable Release" (e.g. v0.42 "Stargate"), a separate release -committee is often established. Stable Releases, and their corresponding release committees are documented -separately in [Stable Release Policy](./RELEASE_PROCESS.md#stable-release-policy)* diff --git a/README.md b/README.md index 9e3d8c712f..7a76ef4284 100644 --- a/README.md +++ b/README.md @@ -45,11 +45,6 @@ For more information, see the [Cosmos SDK Documentation](https://docs.cosmos.net The Cosmos SDK maintains a set of modules that can be included in your blockchain application. For more information on modules, see our [introduction doc](./x/README.md). -## Contributing - -See [CONTRIBUTING.md](./CONTRIBUTING.md) for details on how to contribute and participate in our [dev calls](./CONTRIBUTING.md#teams-dev-calls). -If you want to follow the updates or learn more about the latest design then join our [Discord](https://discord.com/invite/cosmosnetwork). - ## Tools and Frameworks The Cosmos ecosystem is vast. diff --git a/RELEASE_PROCESS.md b/RELEASE_PROCESS.md deleted file mode 100644 index 44ae30a180..0000000000 --- a/RELEASE_PROCESS.md +++ /dev/null @@ -1,248 +0,0 @@ -# Release Process - -This document outlines the process for releasing a new version of Cosmos SDK, which involves major release and patch releases as well as maintenance for the major release. - -> **Note, the Cosmos SDK went directly from v0.47 to v0.50 and skipped the v0.48 and v0.49 versions.** - -## Major Release Procedure - -A _major release_ is an increment of the first number (eg: `v1.2` → `v2.0.0`) or the _point number_ (eg: `v1.1.0 → v1.2.0`, also called _point release_). Each major release opens a _stable release series_ and receives updates outlined in the [Major Release Maintenance](#major-release-maintenance)_section. - -Before making a new _major_ release we do beta and release candidate releases. For example, for release 1.0.0: - -```text -v1.0.0-beta1 → v1.0.0-beta2 → ... → v1.0.0-rc1 → v1.0.0-rc2 → ... → v1.0.0 -``` - -* Release a first beta version on the `main` branch and freeze `main` from receiving any new features. After beta is released, we focus on releasing the release candidate: - * finish audits and reviews - * kick off a large round of simulation testing (e.g. 400 seeds for 2k blocks) - * perform functional tests - * add more tests - * release new beta version as the bugs are discovered and fixed. -* After the team feels that the `main` works fine we create a `release/vY` branch (going forward known a release branch), where `Y` is the version number, with the patch part substituted to `x` (eg: 0.42.x, 1.0.x). Ensure the release branch is protected so that pushes against the release branch are permitted only by the release manager or release coordinator. - * **PRs targeting this branch can be merged _only_ when exceptional circumstances arise** - * update the GitHub mergify integration by adding instructions for automatically backporting commits from `main` to the `release/vY` using the `backport/Y` label. -* In the release branch prepare a new version section in the `CHANGELOG.md` - * All links must point to their respective pull request. - * The `CHANGELOG.md` must contain only the changes of that specific released version. All other changelog entries must be deleted and linked to the `main` branch changelog ([example](https://github.com/cosmos/cosmos-sdk/blob/release/v0.46.x/CHANGELOG.md#previous-versions)). - * Create release notes, in `RELEASE_NOTES.md`, highlighting the new features and changes in the version. This is needed so the bot knows which entries to add to the release page on GitHub. - * Additionally verify that the `UPGRADING.md` file is up to date and contains all the necessary information for upgrading to the new version. -* Remove GitHub workflows that should not be in the release branch - * `deploy-docs.yml`: must be removed to avoid duplicate documentation deployment. - * `test.yml`: All standalone go module tests should be removed (expect `./simapp`, and `./tests` and SDK tests). - * These packages are tracked and tested directly on main. - * `build.yml`: Only the SDK and SimApp needs to be built on release branches. - * Tooling is tracked and tested directly on main. -* Create a new annotated git tag for a release candidate (eg: `git tag -a v1.1.0-rc1`) in the release branch. - * from this point we unfreeze main. - * the SDK teams collaborate and do their best to run testnets in order to validate the release. - * when bugs are found, create a PR for `main`, and backport fixes to the release branch. - * create new release candidate tags after bugs are fixed. -* After the team feels the release branch is stable and everything works, create a full release: - * update `CHANGELOG.md`. - * run `gofumpt -w -l .` to format the code. - * create a new annotated git tag (eg `git -a v1.1.0`) in the release branch. - * Create a GitHub release. - -Following _semver_ philosophy, point releases after `v1.0`: - -* must not break API -* can break consensus - -Before `v1.0`, point release can break both point API and consensus. - -## Patch Release Procedure - -A _patch release_ is an increment of the patch number (eg: `v1.2.0` → `v1.2.1`). - -**Patch release must not break API nor consensus.** - -Updates to the release branch should come from `main` by backporting PRs (usually done by automatic cherry pick followed by a PRs to the release branch). The backports must be marked using `backport/Y` label in PR for main. -It is the PR author's responsibility to fix merge conflicts, update changelog entries, and -ensure CI passes. If a PR originates from an external contributor, a core team member assumes -responsibility to perform this process instead of the original author. -Lastly, it is core team's responsibility to ensure that the PR meets all the SRU criteria. - -Point Release must follow the [Stable Release Policy](#stable-release-policy). - -After the release branch has all commits required for the next patch release: - -* Update `CHANGELOG.md` and `RELEASE_NOTES.md` (if applicable). -* Create a new annotated git tag (eg `git -a v1.1.0`) in the release branch. - * If the release is a submodule update, first go the submodule folder and name the tag prepending the path to the version: - `cd core && git -a core/v1.1.0` or `cd tools/cosmovisor && git -a tools/cosmovisor/v1.4.0` -* Create a GitHub release (if applicable). - -## Major Release Maintenance - -Major Release series continue to receive bug fixes (released as a Patch Release) until they reach **End Of Life**. -Major Release series is maintained in compliance with the **Stable Release Policy** as described in this document. - -Only the following major release series have a stable release status: - -* **0.46** is the previous major release and is supported until the release of **0.50.0**. A fairly strict **bugfix-only** rule applies to pull requests that are requested to be included into a not latest stable point-release. -* **0.47** is the last major release and is supported until the release of **0.51.0**. - -The SDK team maintains the last two major releases, any other major release is considered to have reached end of life. -The SDK team will not backport any bug fixes to releases that are not supported. -Widely-used (decided at SDK team's discretion) unsupported releases are considered to be in a security maintenance mode. The SDK team will backport security fixes to these releases. - -## Stable Release Policy - -### Patch Releases - -Once a Cosmos-SDK release has been completed and published, updates for it are released under certain circumstances -and must follow the [Patch Release Procedure](CONTRIBUTING.md#branching-model-and-release). - -### Rationale - -Unlike in-development `main` branch snapshots, **Cosmos SDK** releases are subject to much wider adoption, -and by a significantly different demographic of users. During development, changes in the `main` branch -affect SDK users, application developers, early adopters, and other advanced users that elect to use -unstable experimental software at their own risk. - -Conversely, users of a stable release expect a high degree of stability. They build their applications on it, and the -problems they experience with it could be potentially highly disruptive to their projects. - -Stable release updates are recommended to the vast majority of developers, and so it is crucial to treat them -with great caution. Hence, when updates are proposed, they must be accompanied by a strong rationale and present -a low risk of regressions, i.e. even one-line changes could cause unexpected regressions due to side effects or -poorly tested code. We never assume that any change, no matter how little or non-intrusive, is completely exempt -of regression risks. - -Therefore, the requirements for stable changes are different than those that are candidates to be merged in -the `main` branch. When preparing future major releases, our aim is to design the most elegant, user-friendly and -maintainable SDK possible which often entails fundamental changes to the SDK's architecture design, rearranging and/or -renaming packages as well as reducing code duplication so that we maintain common functions and data structures in one -place rather than leaving them scattered all over the code base. However, once a release is published, the -priority is to minimize the risk caused by changes that are not strictly required to fix qualifying bugs; this tends to -be correlated with minimizing the size of such changes. As such, the same bug may need to be fixed in different -ways in stable releases and `main` branch. - -### Migrations - -See the SDK's policy on migrations [here](https://docs.cosmos.network/main/migrations/intro). - -### What qualifies as a Stable Release Update (SRU) - -* **High-impact bugs** - * Bugs that may directly cause a security vulnerability. - * _Severe regressions_ from a Cosmos-SDK's previous release. This includes all sort of issues - that may cause the core packages or the `x/` modules unusable. - * Bugs that may cause **loss of user's data**. -* Other safe cases: - * Bugs which don't fit in the aforementioned categories for which an obvious safe patch is known. - * Relatively small yet strictly non-breaking features with strong support from the community. - * Relatively small yet strictly non-breaking changes that introduce forward-compatible client - features to smoothen the migration to successive releases. - * Relatively small yet strictly non-breaking CLI improvements. - -### What does not qualify as SRU - -* State machine changes. -* Breaking changes in Protobuf definitions, as specified in [ADR-044](https://github.com/cosmos/cosmos-sdk/blob/main/docs/architecture/adr-044-protobuf-updates-guidelines.md). -* Changes that introduces API breakages (e.g. public functions and interfaces removal/renaming). -* Client-breaking changes in gRPC and HTTP request and response types. -* CLI-breaking changes. -* Cosmetic fixes, such as formatting or linter warning fixes. - -### What pull requests will be included in stable point-releases - -Pull requests that fix bugs and add features that fall in the following categories do not require a **Stable Release Exception** to be granted to be included in a stable point-release: - -* **Severe regressions**. -* Bugs that may cause **client applications** to be **largely unusable**. -* Bugs that may cause **state corruption or data loss**. -* Bugs that may directly or indirectly cause a **security vulnerability**. -* Non-breaking features that are strongly requested by the community. -* Non-breaking CLI improvements that are strongly requested by the community. - -### What pull requests will NOT be automatically included in stable point-releases - -As rule of thumb, the following changes will **NOT** be automatically accepted into stable point-releases: - -* **State machine changes**. -* **Protobug-breaking changes**, as specified in [ADR-044](https://github.com/cosmos/cosmos-sdk/blob/main/docs/architecture/adr-044-protobuf-updates- guidelines.md). -* **Client-breaking changes**, i.e. changes that prevent gRPC, HTTP and RPC clients to continue interacting with the node without any change. -* **API-breaking changes**, i.e. changes that prevent client applications to _build without modifications_ to the client application's source code. -* **CLI-breaking changes**, i.e. changes that require usage changes for CLI users. - - In some circumstances, PRs that don't meet the aforementioned criteria might be raised and asked to be granted a _Stable Release Exception_. - -### Stable Release Exception - Procedure - -1. Check that the bug is either fixed or not reproducible in `main`. It is, in general, not appropriate to release bug fixes for stable releases without first testing them in `main`. Please apply the label [v0.43](https://github.com/cosmos/cosmos-sdk/milestone/26) to the issue. -2. Add a comment to the issue and ensure it contains the following information (see the bug template below): - - * **[Impact]** An explanation of the bug on users and justification for backporting the fix to the stable release. - * A **[Test Case]** section containing detailed instructions on how to reproduce the bug. - * A **[Regression Potential]** section with a clear assessment on how regressions are most likely to manifest as a result of the pull request that aims to fix the bug in the target stable release. - -3. **Stable Release Managers** will review and discuss the PR. Once _consensus_ surrounding the rationale has been reached and the technical review has successfully concluded, the pull request will be merged in the respective point-release target branch (e.g. `release/v0.43.x`) and the PR included in the point-release's respective milestone (e.g. `v0.43.5`). - -#### Stable Release Exception - Bug template - -```md -#### Impact - -Brief xplanation of the effects of the bug on users and a justification for backporting the fix to the stable release. - -#### Test Case - -Detailed instructions on how to reproduce the bug on Stargate's most recently published point-release. - -#### Regression Potential - -Explanation on how regressions might manifest - even if it's unlikely. -It is assumed that stable release fixes are well-tested and they come with a low risk of regressions. -It's crucial to make the effort of thinking about what could happen in case a regression emerges. -``` - -### Stable Release Managers - -The **Stable Release Managers** evaluate and approve or reject updates and backports to Cosmos SDK Stable Release series, -according to the [stable release policy](#stable-release-policy) and [release procedure](#major-release-procedure). -Decisions are made by consensus. - -Their responsibilites include: - -* Driving the Stable Release Exception process. -* Approving/rejecting proposed changes to a stable release series. -* Executing the release process of stable point-releases in compliance with the [Point Release Procedure](CONTRIBUTING.md). - -Currently residing Stable Release Managers: - -* @tac0turtle - Marko Baricevic -* @julienrbrt - Julien Robert - -## Cosmos SDK Modules - -The Cosmos SDK repository is a mono-repo where its Go modules have a different release process and cadence than the Cosmos SDK itself. -There are two types of modules: - -1. Modules that import the Cosmos SDK and depend on a specific version of it. - * Modules to be imported in an app (e.g `x/` modules). - * Modules that are not imported into an app and are a standalone module (e.g. `cosmovisor`). -2. Modules that do not depend on the Cosmos SDK. - -The same changelog procedure applies to all modules in the Cosmos SDK repository, and must be up-to-date with the latest changes before tagging a module version. -Note: The Cosmos SDK team is in an active process of limiting Go modules that depend on the Cosmos SDK. - -### Modules that depend on the Cosmos SDK - -The Cosmos SDK team should strive to release modules that depend on the Cosmos SDK at the same time or soon after a major version Cosmos SDK itself. -Those modules can be considered as part of the Cosmos SDK, but features and improvements are released at a different cadence. - -* When a module is supposed to be used in an app (e.g `x/` modules), due to the dependency on the SDK, tagging a new version of a module must be done from a Cosmos SDK release branch. A compability matrix must be provided in the `README.md` of that module with the corresponding versions. -* Modules that import the SDK but do not need to be imported in an app (`e.g. cosmovisor`) must be released from the `main` branch and follow the process defined below. - -### Modules that do not depend on the Cosmos SDK - -Modules that do not depend on the Cosmos SDK can be released at any time from the `main` branch of the Cosmos SDK repository. - -#### Branches For Go Modules - -Branches that go modules are released from: - -* Store v1 is released from `release/v0.50.x` branch. diff --git a/ROADMAP.md b/ROADMAP.md deleted file mode 100644 index 7ed72ae95e..0000000000 --- a/ROADMAP.md +++ /dev/null @@ -1,270 +0,0 @@ -# Roadmap 2023 - -Welcome to the Cosmos SDK's team roadmap. - -> This document is meant to help the team get feedback on the proposed work and for others to follow where we stand in our process. This will be a living document updated on a regular basis. If you'd like to participate in any workscope or would like to suggest another feature please reach out to [Marko](marko@binary.builders) or [Sam](sam@binary.builders) and we will schedule a call to discuss the feature request. - - -## Q1 - -### Storage - -* [x] [Produce a spec for the new store design](https://github.com/cosmos/cosmos-sdk/issues/12986) - * Research a new design for store. This could entail writing some POC's in order to identify design patterns -* [x] Store as its own go module - * Store module should be its own go.mod without a dependency on the Cosmos SDK -* [ ] [Begin implementation of store v2](https://github.com/cosmos/cosmos-sdk/pull/15028) - * Identify the migration path from store v1 -> store v2 -* [ ] Parallel execution of state - * RFC/ADR is merged into the main on the sdk -* [ ] Optimistic execution - * RFC/ADR is merged into main on the sdk - - -### Client UX - -* [x] Release v1 of query support (auto-cli) - * A version of query support has been merged, documentation is missing -* [ ] Dynamic metadata support - * Dynamic support allows the Cosmos SDK to release a cmd line tool that could work with any chain. - * Add metadata support to latest version of Cosmos SDK and, if possible, backport to older versions -* [x] Multi-chain command **(Done)** - * Release a cmd line tool that can be pointed a grpc endpoint which then can produce cmd lines to interact with the chain -* [x] Auto-cli tx support - * Tx support for auto-cli/hubl - * This would fully remove the need for application developers to write cli commands for their modules -* [ ] [Consensus Key Rotation](https://github.com/cosmos/cosmos-sdk/issues/5231) - - -### Dev UX - -* [x] [Release collections v0.1](https://github.com/cosmos/cosmos-sdk/issues/14300) - * Collections is a new abstraction layer similar to the ORM. In the ADR phase it received support from many in the ecosystem. - * V1 release should allow modules to be migrated to collections. - * Migrate 3 modules to use collections api - * Migrating 3 modules to use collections would help in show users how to migrate users -* [ ] [Release ORM v1](https://github.com/cosmos/cosmos-sdk/issues/11088) -* [x] [Sign mode textual](https://github.com/cosmos/cosmos-sdk/issues/11970) - * Sign mode textual has been under construction for 2 quarters now, this quarter the goal is to move towards v1 and potentially line up a audit before final release. -* [x] Core API - * [Merge ADR for Core API](https://github.com/cosmos/cosmos-sdk/blob/main/docs/architecture/adr-063-core-module-api.md) - * Migrate three modules to use core api -* [x] Module Dependency - * Give three modules their own go.mods -* [ ] [Metamask signing directly into the sdk](https://github.com/cosmos/cosmos-sdk/discussions/13892) -* [ ] [ADR-033 (internal message routing)](https://github.com/cosmos/cosmos-sdk/blob/main/docs/architecture/adr-033-protobuf-inter-module-comm.md) - * Merge internal message router - * Add docs on how to use the router -* [x] [ADR-54 (dependency management)](https://github.com/cosmos/cosmos-sdk/pull/11802) - * Come to consensus on module dependency graph for the future - * Begin socializing conventions -* [ ] [Remove global bech32](https://github.com/cosmos/cosmos-sdk/issues/13140) -* [x] [Auth module](https://github.com/cosmos/cosmos-sdk/issues/14900) - * Produce a spec/ADR on a proposed new auth module. -* [x] [Implement Amino Json encoder](https://github.com/cosmos/cosmos-sdk/issues/10993) - -### Testing - -* [x] [integration testing framework](https://github.com/cosmos/cosmos-sdk/issues/14145) - * design and merge a integration testing framework. - * The goals of the framework would that a module only needs to depend on modules that it depends on outside of testing, not all modules in the sdk like today. - - -### ABCI 2.0 - -Issue: https://github.com/cosmos/cosmos-sdk/issues/12272 - -* [x] [ADR ABCI 2.0](https://github.com/cosmos/cosmos-sdk/issues/14674) - * Write ADR for integration of vote extensions & finalize block - -**Blocked**: - -> once cometBFT has a release candidate of ABCI 2.0 (cmt 0.38) - -* Integrate ABCI 2.0 - -### Security - -* [ ] [Circuit breaker](https://github.com/cosmos/cosmos-sdk/issues/14226) - * Implement the circuit breaker module and prepare releases for Cosmos SDK versions 0.45, 0.46 and 0.47 - - -### IAVL - -* [x] [ADR 001](https://github.com/cosmos/iavl/pull/608) - * Implementation has been completed, waiting on reviewers -* [x] [Prepare the migration path](https://github.com/cosmos/iavl/issues/675) - * Migration path has not been finalized -* [ ] Test on mainnets - * If possible we would like to test the new IAVL design on mainnets to observer behavior changes. - -Issue: https://github.com/cosmos/iavl/issues/548 - -## Q2 - -### Storage - -* [ ] [Storage v2](https://github.com/cosmos/cosmos-sdk/issues/12986) - * Objective: - * Goal is to get 60% of the way through the rewrite of storage - * Begin testing the rewrite on mainnets if possible - * External Audit - * Progress: - * On pause till ABCI 2.0 ships -* [ ] [Optimistic Execution](https://github.com/cosmos/cosmos-sdk/issues/15365) - * Objective: - * Users should be able to pick between delayed execution and optimistic - * RFC/ADR is merged - * Implementation started. - * Progess: - * On pause till ABCI 2.0 is merged - -### Client UX - -* [ ] Hubl/AutoCLI - * Objective: - * Allow users to sign and submit transactions using hubl - * Add module support for autocli - * Deprecate/remove legacy cli (optional) - * Progress: - * Signing support is being refactored and is near completion - * Adapting modules to use autocli instead of manually written cli -* [ ] [Consensus Key Rotation](https://github.com/cosmos/cosmos-sdk/issues/5231) - * Objective: - * Allow users to rotate consensus keys for their validators - * Progress - * Merge pull request and updated ADR into main -* [ ] [Operator key rotation](https://github.com/cosmos/cosmos-sdk/issues/3863) - * Objective: - * Allow users to rotate operator keys for their validators - * Progress: - * secondary val index was added to support operator key rotation - * Pr is open and is being worked on - -### Dev UX - -* Toolkit/SDK ADR. - * Objective: - * Produce a RFC/ADR on how to make core composable - * Merge RFC/ADR into main - * Progress: - * on pause until abci 2.0 integration is completed -* Adopt core api fully in modules - * Objective: - * Remove the Cosmos SDK and Comet as a dependency from all modules - * Release v1 of modules that have their dependency graph cleaned up - * Spin out 4 more modules into their own go.mods - * Progress: - * Core api has been integrated into all modules - * KvStoreService is being added to all modules -* [ ] [Remove global bech32](https://github.com/cosmos/cosmos-sdk/issues/13140) - * Objective: - * Depreacte global bech32 setting - * Progress: - * All modules except bank use the `address.Codec` -* [ ] Make sdk.Msg only be `proto.message` - * Objectives: - * Reduce sdk.Msg to only be proto.message - * Reduce boilerplate in `msgs.go` - * Progess: - * [x] [Make ValidateBasic Optional](https://github.com/cosmos/cosmos-sdk/issues/15648) - * [ ] [Make GetSigners be optional](https://github.com/cosmos/cosmos-sdk/issues/15677) - * [ ] Remove GetsignBytes for legacy amino encoding -* [ ] [Collections](https://github.com/cosmos/cosmos-sdk/issues/14300) - * Objectives - * Migrate all modules - * Add query support - * Add schema support - * Progress: - * We have migrated three modules - -### ABCI 2.0 - -* [ ] [ABCI 2.0](https://github.com/cosmos/cosmos-sdk/issues/12272) - * Objectives: - * Integrate comet 0.38 - * QA - * Progress: - * Integration has started - - -### Testing - -* [ ] [Integration framework](https://github.com/cosmos/cosmos-sdk/issues/14145) - * Objectives: - * Migrate all modules - * Progress: - * We have migrated 2-4 modules currently - -### Modules - -* [ ] [Invariant Checking](https://github.com/cosmos/cosmos-sdk/issues/15706) - * Objective: - * Design a new system for checking invairants - * Implement changes - * Audit current invariants - * Progress: - * NA -* [ ] [Accounts](https://github.com/cosmos/cosmos-sdk/issues/14900) - * Objective: - * Allow users to use account abstractions - * Implementation is completed - * External Audit is scheduled (if needed) - * Progress: - * RFC/ADR is in review - -### Research - -* [ ] Commitment Structure - * Objective: - * Identify different commitment structures that could be used in the sdk and how they would be plugged (highlevel) - * Progress: - * Conversations in slack have started -* [ ] Cross lang - * Objective: - * Answer, what is needed to support many languages - * Answer, what sort of encoding of passing between the cgo/ffi boundary - * Progress: - * working group is meeting bi weekly - * ADR/RFC is in review - -## Q3 - -### Storage - -* Audit & release of storage refactor -* Identify further optimizations for storage - * Goal is to identify the next bottlenecks in storage or the state machine - -### Dev UX - -* Complete Toolkit/SDK implementation refactor - * Goal is to release the new version of the sdk allowing for further composability -* Implement fee market abstractions - * Goal is to release an alpha version of fee market abstractions - -### Modules - -* Governance - * Make gov and groups composable with each other, not duplicate -* Staking - * Research a new staking design - * Begin Implementation - - -### Research - -* Nonce Lanes - * Goal is to produce a spec and/or viability of using lanes for nonces instead of a single sequence number. - -## Q4 - -### Research - -* Stateless clients - * research how stateless clients could evolve in cosmos - - - - -This document will be updated at the end of the quarter on what was achieved and what was not. Shortly before the quarter concludes a new section will be added for the next quarter. We are working on updating the complete one year roadmap and will be posting it here as well. diff --git a/cliff.toml b/cliff.toml deleted file mode 100644 index 7c023e1b54..0000000000 --- a/cliff.toml +++ /dev/null @@ -1,128 +0,0 @@ -# configuration file for git-cliff (0.1.0) - -[changelog] -# changelog header -header = """ - - -# Changelog - -""" -# template for the changelog body -body = """ -{% if version %}\ - ## [{{ version }}](https://github.com/cosmos/cosmos-sdk/releases/tag/{{version}}) - {{ timestamp | date(format="%Y-%m-%d") }} -{% else %}\ - ## [Unreleased] -{% endif %}\ -{% for group, commits in commits | group_by(attribute="group") %} - ### {{ group | striptags | trim | upper_first }} - {% for commit in commits %} - * {{ commit.message | upper_first }}\ - {% endfor %} -{% endfor %}\n -""" -# remove the leading and trailing whitespace from the template -trim = true -# changelog footer -footer = """ - -""" - -[git] -# parse the commits based on https://www.conventionalcommits.org -conventional_commits = true -# filter out the commits that are not conventional -filter_unconventional = true -# process each line of a commit as an individual commit -split_commits = true -# regex for preprocessing the commit messages -commit_preprocessors = [ - { pattern = '.*', replace_command = 'sed -E "s/^(\S+)\s(.+)\s\((#[0-9]+)\)$/\1 (\3) \2/"' }, - # A reference to an issue is appened to commits that looks like "(#1234)", this will be replaced - # with a link to that issue, e.g. "[#$1234](https://github.com/cosmos/cosmos-sdk/issues/1234)". - { pattern = '\(#(\d+)\)', replace = "[#${1}](https://github.com/cosmos/cosmos-sdk/issues/${1})" }, - # replace multiple spaces with one space - { pattern = " +", replace = " "}, - - # the following patterns only exist because "split_commits" is set to true, and we are processesing - # each line of the commit as a separate message. - # these exist to filter out common messages that appear in commit messages that are technically - # conventional, but we do not way to include in the changelog. - { pattern = '^Signed-off-by:.*', replace='' }, - { pattern = '^Co-authored-by:.*', replace='' }, - # don't include references to issues as changelog entries. - { pattern = '^ref:.*', replace='' }, - # exclude CVSS format, CVE can still be included in regular conventinal commits. - { pattern = 'CVSS:.*', replace='' }, - # don't include dependabot auto merge entries. - { pattern = '.*dependabot-automerge-.*', replace='' }, - # don't include statements saying which issue is closed. - { pattern = '^closes:.*|Closes:.*', replace='' }, - # remove standalone links in the commit messages. - { pattern = '^https://.*', replace='' }, - # remove lines with html. - { pattern = '^<.*', replace='' }, -] - -# regex for parsing and grouping commits -commit_parsers = [ - # specifying the number in a comment is a workaround to enable ordering of groups. - # these comments are stripped out of the markdown with the filter "{{ group | striptags | trim | upper_first }}" - # above in the body template. - { message = "^((?i)feature|(?i)feat)", group = "Features" }, - { message = "^((?i)improvements|(?i)imp|(?i)impr|(?i)perf)", group = "Improvements" }, - { message = "^((?i)fix|(?i)bug)", group = "Bug Fixes" }, - { message = '^.*\(api\)!', group = "API Breaking" }, - { message = '^.*\(statemachine\)!', group = "State Machine Breaking" }, - { message = "^((?i)test)", group = "Testing" }, - { message = "^((?i)doc|(?i)docs|(?i)documentation)", group = "Documentation" }, - { message = "^((?i)deprecated)", group = "Deprecated" }, - { message = "^((?i)deps|(?i)dep|(?i)build)", group = "Dependencies" }, - { message = "^revert|^ci|^chore|^refactor", skip = true} # explicitly skips changelog for reverts, CI, chore and refactor commits -] -# filter out the commits that are not matched by commit parsers -filter_commits = true -# glob pattern for matching git tags -# note SDK tags are purposely ignored, only submodules are included. -tag_pattern = "**/v[0-9]*" -# regex for skipping tags -skip_tags = "" -# regex for ignoring tags -ignore_tags = "" -# sort the tags chronologically -date_order = false -# sort the commits inside sections by oldest/newest order -sort_commits = "newest" \ No newline at end of file diff --git a/docs/README.md b/docs/README.md index ea2f47ced4..6c498d6a66 100644 --- a/docs/README.md +++ b/docs/README.md @@ -1,7 +1,5 @@ # Updating the docs -If you want to open a PR in Cosmos SDK to update the documentation, please follow the guidelines in [`CONTRIBUTING.md`](https://github.com/cosmos/cosmos-sdk/tree/main/CONTRIBUTING.md#updating-documentation) and the [Documentation Writing Guidelines](./DOC_WRITING_GUIDELINES.md). - ## Stack The documentation for Cosmos SDK is hosted at https://docs.cosmos.network and built from the files in the `/docs` directory.