b1f9a117f7
Bumps [github.com/jhump/protoreflect](https://github.com/jhump/protoreflect) from 1.10.2 to 1.10.3. <details> <summary>Release notes</summary> <p><em>Sourced from <a href="https://github.com/jhump/protoreflect/releases">github.com/jhump/protoreflect's releases</a>.</em></p> <blockquote> <h2>v1.10.3</h2> <p>This release contains several fixes to the <code>desc/protoparse</code> package and one fix to the <code>grpcreflect</code> package.</p> <h3>"github.com/jhump/protoreflect/desc/protoparse"</h3> <p>Changes/fixes:</p> <ul> <li>If a custom option value contains a message literal, <code>protoc</code> accepts identifiers <code>t</code>, <code>f</code>, <code>True</code>, and <code>False</code> as synonyms for <code>true</code> and <code>false</code>. Use of these alternate spellings would be rejected by this package. This is now fixed so that this package accepts the same values as <code>protoc</code>.</li> <li>If a custom option refers to an enum which has values named <code>true</code> or <code>false</code>, this package would reject the option, misunderstanding the <code>true</code> or <code>false</code> identifier to be a boolean literal instead of an enum value name. This has been fixed.</li> <li>There were several cases where references to a custom option or extension, in an option name or in a message literal, were resolved differently by this package than by <code>protoc</code>. This lead to some variances -- some source files that <code>protoc</code> would accept but that this package would not (because it was unable to resolve a reference), and some source files that this package would accept but that <code>protoc</code> would reject (because this package was using different lexical scoping rules during resolution). This has been fixed and this package now resolves extension names the same way as <code>protoc</code>.</li> <li>When specifying a custom option value for a message whose type is <code>google.protobuf.Any</code>, <code>protoc</code> supports a special syntax that makes it possible to use a simple text format for the contained message, instead of having to include a byte string representation of a marshaled/encoded value. This package did not previously implement that syntax, so would reject proto sources that used it. This has been remedied, and the special syntax is now supported by this package.</li> <li>This package would previously accept a <code>repeated</code> extension for a message that used message-set wire format. However, only <code>optional</code> extensions are allowed for such messages. This has been fixed, and proto sources that try to define such a <code>repeated</code> extension will be rejected.</li> <li>Extensions are not allowed to set a <code>json_name</code> option, however this package was accepting proto sources that did so. This has been fixed, and proto sources that define an extension with the <code>json_name</code> option will be rejected.</li> </ul> <h3>"github.com/jhump/protoreflect/grpcreflect"</h3> <p>Changes/fixes:</p> <ul> <li>In some cases, servers implementing the reflection service has been observed to incorrectly include extra file descriptors in response to a <code>file_containing_symbol</code> request. Also, the reflection service does not actually specify any ordering requirements for responses that choose to include more than one file. But this package mistakenly assumed an ordering (based on an older implementation of the reflection service in the official Java runtime), which could cause such cases (responses with multiple or even superfluous files) to return the incorrect file descriptor. This has been fixed. Now all responses to <code>file_containing_symbol</code>, <code>file_containing_extension</code> and <code>file_by_filename</code> requests correctly support multiple files (even superfluous ones) in any order.</li> </ul> </blockquote> </details> <details> <summary>Commits</summary> <ul> <li><a href=" |
||
|---|---|---|
| .github | ||
| api | ||
| baseapp | ||
| client | ||
| codec | ||
| container | ||
| contrib | ||
| cosmovisor | ||
| crypto | ||
| db | ||
| doc | ||
| docs | ||
| errors | ||
| internal | ||
| orm | ||
| proto | ||
| scripts | ||
| server | ||
| simapp | ||
| snapshots | ||
| std | ||
| store | ||
| telemetry | ||
| tests | ||
| testutil | ||
| third_party/proto | ||
| types | ||
| version | ||
| x | ||
| .build.sh | ||
| .clang-format | ||
| .codecov.yml | ||
| .deepsource.toml | ||
| .dockerignore | ||
| .gitattributes | ||
| .gitignore | ||
| .golangci.yml | ||
| .goreleaser.yml | ||
| .markdownlint.json | ||
| .markdownlintignore | ||
| .mergify.yml | ||
| CHANGELOG.md | ||
| CODE_OF_CONDUCT.md | ||
| CODING_GUIDELINES.md | ||
| CONTRIBUTING.md | ||
| Dockerfile | ||
| LICENSE | ||
| Makefile | ||
| README.md | ||
| RELEASE_PROCESS.md | ||
| SECURITY.md | ||
| buf.work.yaml | ||
| docker-compose.yml | ||
| go.mod | ||
| go.sum | ||
README.md
Cosmos SDK
The Cosmos SDK is a framework for building blockchain applications. Tendermint Core (BFT Consensus) and the Cosmos SDK are written in the Golang programming language. Cosmos SDK is used to build Gaia, the first implementation of the Cosmos Hub.
WARNING: The Cosmos SDK has mostly stabilized, but we are still making some breaking changes.
Note: Requires Go 1.17+
Quick Start
To learn how the Cosmos SDK works from a high-level perspective, see the Cosmos SDK High-Level Intro.
If you want to get started quickly and learn how to build on top of Cosmos SDK, visit Cosmos SDK Tutorials. You can also fork the tutorial's repository to get started building your own Cosmos SDK application.
For more information, see the Cosmos SDK Documentation.
Contributing
See CONTRIBUTING.md for details how to contribute and participate in our dev calls. If you want to follow the updates or learn more about the latest design then join our Discord.
Tools and Frameworks
The Cosmos ecosystem is vast. We will only make a few notable mentions here.
- Tools: notable frameworks and modules.
- CosmJS: the Swiss Army knife to power JavaScript based client solutions.
Cosmos Hub Mainnet
The Cosmos Hub application, gaia, has moved to its own cosmos/gaia repository. Go there to join the Cosmos Hub mainnet and more.
Inter-Blockchain Communication (IBC)
The IBC module for the Cosmos SDK has moved to its own cosmos/ibc-go repository. Go there to build and integrate with the IBC module.
Starport
Starport is the all-in-one platform to build, launch, and maintain any crypto application on a sovereign and secured blockchain. If you are building a new app or a new module, use Starport to get started and speed up development.
Disambiguation
This Cosmos SDK project is not related to the React-Cosmos project (yet). Many thanks to Evan Coury and Ovidiu (@skidding) for this Github organization name. As per our agreement, this disambiguation notice will stay here.