LaconicNetwork/cosmos-sdk
7
0
Fork 0
Code Issues Pull Requests Packages Projects Releases 2 Wiki Activity

chore: clean repo (#24723)

Browse Source
This commit is contained in:
Alex | Interchain Labs
2025-05-08 15:44:28 -04:00
committed by GitHub
parent 5d28bf5540
commit acb3d74760
18 changed files with 0 additions and 1605 deletions
Download Patch File Download Diff File Expand all files Collapse all files
.github/ISSUE_TEMPLATE/bug-report.md
-30
View File
@@ -1,30 +0,0 @@
---
name: Bug Report
about: Create a report to help us squash bugs!
title: "[Bug]: "
labels: "T:Bug"
---
<!-- < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < ☺
v ✰ Thanks for opening an issue! ✰
v Before smashing the submit button please review the template.
v Please also ensure that this is not a duplicate issue :)
☺ > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -->
<!--
IMPORTANT: Prior to opening a bug report, check if it affects one of the core modules
and if its elegible for a bug bounty on `SECURITY.md`. Bugs that are not submitted
through the appropriate channels won't receive any bounty.
-->
## Summary of Bug
<!-- Concisely describe the issue -->
## Version
<!-- git commit hash or release version -->
## Steps to Reproduce
<!-- What commands in order should someone run to reproduce your problem? -->
.github/ISSUE_TEMPLATE/bug-report.yml
-49
View File
@@ -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
.github/ISSUE_TEMPLATE/documentation.yml
-18
View File
@@ -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
.github/ISSUE_TEMPLATE/epics.md
-31
View File
@@ -1,31 +0,0 @@
---
name: Epic
about: Create an epic/user
title: "[Epic]: "
labels: T:Epic
---
<!-- < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < ☺
v ✰ Thanks for opening an issue! ✰
v Before smashing the submit button please review the template.
v Word of caution: poorly thought-out proposals may be rejected
v without deliberation
☺ > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -->
## Summary
<!-- Short, concise description of the proposed feature/changes to the repository
What are the user needs?
How could this solution fix the user facing problem? -->
## Problem Definition
<!-- 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? -->
## Work Breakdown
<!-- 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. -->
.github/ISSUE_TEMPLATE/epics.yml
-43
View File
@@ -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
.github/ISSUE_TEMPLATE/feature-request.md
-28
View File
@@ -1,28 +0,0 @@
---
name: Feature Request
about: Create a proposal to request a feature
title: "[Feature]: "
labels: T:feature-request
---
<!-- < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < ☺
v ✰ Thanks for opening an issue! ✰
v Before smashing the submit button please review the template.
v Word of caution: poorly thought-out proposals may be rejected
v without deliberation
☺ > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -->
## Summary
<!-- Short, concise description of the proposed feature -->
## Problem Definition
<!-- 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? -->
## Proposal
<!-- Detailed description of requirements of implementation -->
.github/ISSUE_TEMPLATE/feature-request.yml
-41
View File
@@ -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
.github/ISSUE_TEMPLATE/module-readiness-checklist.md
-40
View File
@@ -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
.github/ISSUE_TEMPLATE/qa.md
-87
View File
@@ -1,87 +0,0 @@
<!-- < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < ☺
v ✰ Thanks for opening an issue! ✰
v Before smashing the submit button please review the template.
v Word of caution: poorly thought-out proposals may be rejected
v without deliberation
☺ > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -->
## Summary
<!-- In a few short sentences summarize the release -->
## Major Changes
<!-- Describe the major changes associated to this release -->
## Gotchas
<!-- Gotchas is an area which changes could of been made that the auditors should be aware of -->
## 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
.github/PULL_REQUEST_TEMPLATE.md
-32
View File
@@ -4,35 +4,3 @@ Closes: #XXXX
<!-- Add a description of the changes that this PR introduces and the files that
are the most critical to review. -->
---
## 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:
<!-- * `feat`: A new feature
* `fix`: A bug fix
* `docs`: Documentation only changes
* `style`: Changes that do not affect the meaning of the code (white-space, formatting, missing semi-colons, etc)
* `refactor`: A code change that neither fixes a bug nor adds a feature
* `perf`: A code change that improves performance
* `test`: Adding missing tests or correcting existing tests
* `build`: Changes that affect the build system or external dependencies (example scopes: gulp, broccoli, npm)
* `ci`: Changes to our CI configuration files and scripts (example scopes: Travis, Circle, BrowserStack, SauceLabs)
* `chore`: Other changes that don't modify src or test files
* `revert`: Reverts a previous commit -->
* [ ] 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
CODE_OF_CONDUCT.md
-46
View File
@@ -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/
CODING_GUIDELINES.md
-152
View File
@@ -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
`<desc>, tc #<index>, i #<index>`.
`<desc>` 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
<some table>
for tcIndex, tc := range cases {
<some code>
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.
CONTRIBUTING.md
-355
View File
@@ -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: <description>`). 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)*
README.md
-5
View File
@@ -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.
RELEASE_PROCESS.md
-248
View File
@@ -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.
ROADMAP.md
-270
View File
@@ -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.
cliff.toml
-128
View File
@@ -1,128 +0,0 @@
# configuration file for git-cliff (0.1.0)
[changelog]
# changelog header
header = """
<!--
Guiding Principles:
Changelogs are for humans, not machines.
There should be an entry for every single version.
The same types of changes should be grouped.
Versions and sections should be linkable.
The latest version comes first.
The release date of each version is displayed.
Mention whether you follow Semantic Versioning.
Usage:
Changelog entries are generated by git cliff ref: https://github.com/orhun/git-cliff
Each commit should be conventional, the following message groups are supported.
* feat: A new feature
* fix: A bug fix
* docs: Documentation only changes
* style: Changes that do not affect the meaning of the code (white-space, formatting, missing semi-colons, etc)
* refactor: A code change that neither fixes a bug nor adds a feature
* perf: A code change that improves performance
* test: Adding missing tests or correcting existing tests
* build: Changes that affect the build system or external dependencies (example scopes: go, npm)
* ci: Changes to our CI configuration files and scripts (example scopes: GH Actions)
* chore: Other changes that don't modify src or test files
* revert: Reverts a previous commit
When a change is made that affects the API or state machine, the commit message prefix should be suffixed with `!`.
Ref: https://github.com/commitizen/conventional-commit-types/blob/v3.0.0/index.json
-->
# 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 = """
<!-- generated by git-cliff -->
"""
[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 = "<!-- 0 -->Features" },
{ message = "^((?i)improvements|(?i)imp|(?i)impr|(?i)perf)", group = "<!-- 1 -->Improvements" },
{ message = "^((?i)fix|(?i)bug)", group = "<!-- 2 -->Bug Fixes" },
{ message = '^.*\(api\)!', group = "<!-- 3 -->API Breaking" },
{ message = '^.*\(statemachine\)!', group = "<!-- 4 -->State Machine Breaking" },
{ message = "^((?i)test)", group = "<!-- 5 -->Testing" },
{ message = "^((?i)doc|(?i)docs|(?i)documentation)", group = "<!-- 6 -->Documentation" },
{ message = "^((?i)deprecated)", group = "<!-- 7 -->Deprecated" },
{ message = "^((?i)deps|(?i)dep|(?i)build)", group = "<!-- 8 -->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"
docs/README.md
-2
View File
@@ -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.