chore: merge Cosmos-SDK v0.44.0

CHANGELOG.md

@@ -35,6 +35,33 @@ Ref: https://keepachangelog.com/en/1.0.0/
 
 # Changelog
 
+## [Unreleased]
+
+## [v0.44.0](https://github.com/cosmos/cosmos-sdk/releases/tag/v0.44.0) - 2021-09-01
+
+### Features
+
+* [\#9860](https://github.com/cosmos/cosmos-sdk/pull/9860) Emit transaction fee in ante handler fee decorator. The event type is `tx` and the attribute is `fee`.
+
+### Improvements
+
+* (deps) [\#9956](https://github.com/cosmos/cosmos-sdk/pull/9956) Bump Tendermint to [v0.34.12](https://github.com/tendermint/tendermint/releases/tag/v0.34.12).
+
+### Deprecated
+
+* (x/upgrade) [\#9906](https://github.com/cosmos/cosmos-sdk/pull/9906) Deprecate `UpgradeConsensusState` gRPC query since this functionality is only used for IBC, which now has its own [IBC replacement](https://github.com/cosmos/ibc-go/blob/2c880a22e9f9cc75f62b527ca94aa75ce1106001/proto/ibc/core/client/v1/query.proto#L54)
+
+### Bug Fixes
+
++ [\#9965](https://github.com/cosmos/cosmos-sdk/pull/9965) Fixed `simd version` command output to report the right release tag.
++
+### API Breaking Changes
+* (client/tx) [\#9421](https://github.com/cosmos/cosmos-sdk/pull/9421/) `BuildUnsignedTx`, `BuildSimTx`, `PrintUnsignedStdTx` functions are moved to
+  the Tx Factory as methods.
+
+### Client Breaking Changes
+* [\#10041](https://github.com/cosmos/cosmos-sdk/pull/10041) Remove broadcast & encode legacy REST endpoints. Please see the [REST Endpoints Migration guide](https://docs.cosmos.network/master/migrations/rest.html) to migrate to the new REST endpoints.
+
 ## [v0.43.0](https://github.com/cosmos/cosmos-sdk/releases/tag/v0.43.0) - 2021-08-10
 
 ### Features
@@ -59,7 +86,6 @@ Ref: https://keepachangelog.com/en/1.0.0/
 * [\#8518](https://github.com/cosmos/cosmos-sdk/pull/8518) Help users of multisig wallets debug signature issues.
 * [\#9750](https://github.com/cosmos/cosmos-sdk/pull/9750) Emit events for tx signature and sequence, so clients can now query txs by signature (`tx.signature='<base64_sig>'`) or by address and sequence combo (`tx.acc_seq='<addr>/<seq>'`).
 
-
 ### Client Breaking Changes
 
 * [\#8363](https://github.com/cosmos/cosmos-sdk/pull/8363) Addresses no longer have a fixed 20-byte length. From the SDK modules' point of view, any 1-255 bytes-long byte array is a valid address.
@@ -124,7 +150,6 @@ Ref: https://keepachangelog.com/en/1.0.0/
 * (x/capability) [\#9836](https://github.com/cosmos/cosmos-sdk/pull/9836) Removed `InitializeAndSeal(ctx sdk.Context)` and replaced with `Seal()`. App must add x/capability module to the begin blockers which will assure that the x/capability keeper is properly initialized. The x/capability begin blocker must be run before any other module which uses x/capability.
 
 
-
 ### State Machine Breaking
 
 * (x/{bank,distrib,gov,slashing,staking}) [\#8363](https://github.com/cosmos/cosmos-sdk/issues/8363) Store keys have been modified to allow for variable-length addresses.
@@ -203,7 +228,7 @@ Ref: https://keepachangelog.com/en/1.0.0/
 * [\#9720](https://github.com/cosmos/cosmos-sdk/pull/9720) Feegrant grant cli granter now accepts key name as well as address in general and accepts only address in --generate-only mode
 * [\#9766](https://github.com/cosmos/cosmos-sdk/pull/9766) Fix hardcoded ledger signing algorithm on `keys add` command.
 * [\#9793](https://github.com/cosmos/cosmos-sdk/pull/9793) Fixed ECDSA/secp256r1 transaction malleability.
-* (server) [#9704](https://github.com/cosmos/cosmos-sdk/pull/9704) Start GRPCWebServer in goroutine, avoid blocking other services from starting.
+* (server) [#9704](https://github.com/cosmos/cosmos-sdk/pull/9704) Start GRPCWebServer in goroutine, avoid blocking other services from starting.
 * (bank) [\#9687](https://github.com/cosmos/cosmos-sdk/issues/9687) fixes [\#9159](https://github.com/cosmos/cosmos-sdk/issues/9159). Added migration to prune balances with zero coins.
 
 

Makefile

@@ -2,7 +2,7 @@
 
 PACKAGES_NOSIMULATION=$(shell go list ./... | grep -v '/simulation')
 PACKAGES_SIMTEST=$(shell go list ./... | grep '/simulation')
-VERSION := $(shell echo $(shell git describe --always) | sed 's/^v//')
+VERSION := $(shell echo $(shell git describe --always --match "v*") | sed 's/^v//')
 TMVERSION := $(shell go list -m github.com/tendermint/tendermint | sed 's:.* ::')
 COMMIT := $(shell git log -1 --format='%H')
 LEDGER_ENABLED ?= true

RELEASE_NOTES.md

@@ -1,54 +1,21 @@
-# Cosmos SDK v0.43.0 Release Notes
+# Cosmos SDK v0.44.0 Release Notes
 
-This release introduces several new important updates to the Cosmos SDK. The release notes below provide an overview of the larger high-level changes introduced in the v0.43 release series.
+v0.44 is a security release which contains a consensus breaking change.
+It doesn't bring any new feature and it's a logical continuation of v0.43.
 
-That being said, this release does contain many more minor and module-level changes besides those mentioned below. For a comprehsive list of all breaking changes and improvements since the v0.42 "Stargate" release series, please see the [CHANGELOG](https://github.com/cosmos/cosmos-sdk/blob/v0.43.0/CHANGELOG.md).
+Consequences:
++ v0.43 is discontinued;
++ all chains should upgrade to v0.44. Update from v0.43 doesn't require any migration. Chains can upgrade directly from v0.42, in that case v0.43 migrations must be executed when upgrading to v0.44;
++ all previously planned features for v0.44 are going to land in v0.45, with the same release schedule.
 
-## Two new modules: `x/authz` and `x/feegrant`
+NOTE: v0.42 release will reach end of life on September 8, 2021.
 
-The v0.43 release focused on simplifying [keys and fee management](https://github.com/cosmos/cosmos-sdk/issues/7074) for SDK users, by introducing the two following modules:
+Please see [Cosmos SDK v0.43.0 Release Notes](https://github.com/cosmos/cosmos-sdk/blob/v0.43.0/RELEASE_NOTES.md).
 
-- `x/feegrant` allows one account, the "granter" to grant another account, the "grantee" an allowance to spend the granter's account balance for fees within certain well-defined limits. It solves the problem of signing accounts needing to possess a sufficient balance in order to pay fees.
-  - See [ADR-029](https://github.com/cosmos/cosmos-sdk/blob/8f21e26a6506c9ee81686bad6cf9be3f0e8e11d7/docs/architecture/adr-029-fee-grant-module.md) introducing the module.
-  - Read the [documentation](https://docs.cosmos.network/master/modules/feegrant/).
-  - Check out its [Protobuf definitions](https://github.com/cosmos/cosmos-sdk/tree/master/proto/cosmos/feegrant/v1beta1).
-- `x/authz` provides functionality for granting arbitrary privileges from one account (the "granter") to another account (the "grantee"). These privileges, called [`Authorization`](https://github.com/cosmos/cosmos-sdk/blob/f2cea6a137ce19ad8987fa8a0cb99f4b37c4484d/x/authz/authorizations.go#L11)s in the code, can for example allow grantees to execute `Msg`s on behalf of the granter.
-  - See [ADR-030](https://github.com/cosmos/cosmos-sdk/blob/8f21e26a6506c9ee81686bad6cf9be3f0e8e11d7/docs/architecture/adr-030-authz-module.md) introducing the module.
-  - Read the [documentation](https://docs.cosmos.network/master/modules/authz/).
-  - Check out its [Protobuf definitions](https://github.com/cosmos/cosmos-sdk/tree/master/proto/cosmos/authz/v1beta1).
+## Updates
 
-These two modules have a slightly different folder structure compared to previously existing modules. For example, all Protobuf-generated files are generated in the module root folder instead of the `types/` folder, and the module itself is defined inside a `module` sub-package. Moving forward, we believe this folder structure is clearer and sets a better example for module developers. To learn more about building modules following this structure, please read our [building modules](https://docs.cosmos.network/master/building-modules/intro.html) documentation.
+For a comprehensive list of all breaking changes and improvements since the v0.42 "Stargate" release series, please see the **[CHANGELOG](https://github.com/cosmos/cosmos-sdk/blob/release/v0.44.x/CHANGELOG.md)**.
 
-## ADR-028 Addresses
+### Client Breaking Changes
 
-In the SDK versions v0.42 and earlier, addresses were all 20-bytes long, generated by truncating the first 20 bytes of the SHA-256 hash of some given bytes (e.g. the public key for normal accounts, or the module name for module accounts). Unfortunately, this significantly decreases the security of Cosmos SDK due to address space collisions.
-
-ADR-028 introduces a new specification for deriving addresses for all kinds of addressable accounts. Following is a quick summary:
-
-- secp256k1 public keys still have 20-byte addresses to keep backwards-compatibility,
-- new public key types (e.g. ed25519) and module accounts will have 32-byte address to increase collision resistance,
-- new algorithms have also been specified for composed accounts (like multisigs) or derived accounts (like module sub-accounts).
-
-[Link to ADR-028](https://github.com/cosmos/cosmos-sdk/blob/master/docs/architecture/adr-028-public-key-addresses.md).
-
-## ADR-041 In-place store migrations
-
-Chain upgrades were historically done with the Cosmos SDK by creating an upgrade proposal, halting the chain at the given height, exporting state to a JSON file, making the necessary JSON file changes, and creating a new chain with the modified JSON file as genesis. This procedure is tedious, and could take up to several hours.
-
-Cosmos SDK v0.43 introduces a new way of handling upgrades. When an upgrade happens, instead of starting a new chain, the new binary will read the existing database, and perform in-place modifications of the store. We expect this method to significantly reduce the migration time.
-
-For more information:
-
-- see the [upgrading modules](https://docs.cosmos.network/master/building-modules/upgrade.html) documentation to learn how to modify your module to be able to support in-place store migrations,
-- check out how to [set up an upgrade handler](https://docs.cosmos.network/master/core/upgrade.html) that perform in-place store migrations in your `app.go`,
-- read [ADR-041](https://github.com/cosmos/cosmos-sdk/blob/master/docs/architecture/adr-041-in-place-store-migrations.md) introducing this feature.
-
-## Protobuf Client-Side Breaking Changes
-
-In this release, we deprecated a couple of fields in our Protobuf definitions. When using these fields, some changes in behavior might occur whether you're hitting an v0.42 or a v0.43 node.
-
-- `cosmos.gov.v1beta1.Vote#option` is deprecated in favor of `cosmos.gov.v1beta1.Vote#options` (with an "s") to support x/gov [split votes](https://github.com/cosmos/cosmos-sdk/blob/master/docs/architecture/adr-037-gov-split-vote.md). There are no breaking changes in `Msg`s, as a new `MsgWeightedVote` has been added to support split votes. However, when querying, the deprecated `option` field is populated only when the underlying vote has one VoteOption with weight 1. For other split votes, the `option` field will be equal to `OptionEmpty`.
-- `cosmos.upgrade.v1beta1.Plan#time` is deprecated, because the SDK stops supporting time-based upgrades in favor or height-based upgrades. If an upgrade Plan is created with a non-empty time, the node will error.
-- `cosmos.upgrade.v1beta1.Plan#upgraded_client_state` is deprecated as IBC logic has been moved to the IBC repo. If this field is set, the node will error.
-
-The SDK team is planning to document Protobuf change process using an ADR. It will be a guideline for all chain developers, follow [#9477](https://github.com/cosmos/cosmos-sdk/issues/9477) for more info.
+* Remove broadcast & encode legacy REST endpoints. Both requests should use the new gRPC-Gateway REST endpoints. Please see the [REST Endpoints Migration guide](https://docs.cosmos.network/master/migrations/rest.html) to migrate to the new REST endpoints.

STABLE_RELEASES.md

@@ -4,16 +4,16 @@
 
 Only the following release series are currently supported and receive bug fixes:
 
-* **0.39 «Launchpad»** will be supported until 6 months after **0.42.0** is published. A fairly strict **bugfix-only** rule applies to pull requests that are requested to be included into a stable point-release.
-* **0.42 «Stargate»** is the latest stable release.
+* **0.42 «Stargate»** will be supported until 6 months after **0.43.0** is published. A fairly strict **bugfix-only** rule applies to pull requests that are requested to be included into a stable point-release.
+* **0.43 «Stargate»** is the latest stable release.
 
-The **0.42 «Stargate»** release series is maintained in compliance with the **Stable Release Policy** as described in this document.
+The **0.43 «Stargate»** release series is maintained in compliance with the **Stable Release Policy** as described in this document.
 
 ## Stable Release Policy
 
 This policy presently applies *only* to the following release series:
 
-* **0.42 «Stargate»**
+* **0.43 «Stargate»**
 
 ### Point Releases
 
@@ -47,7 +47,7 @@ ways in stable releases and `master` branch.
 
 ### Migrations
 
-To smoothen the update to the latest stable release, the SDK includes a set of CLI commands for managing migrations between SDK versions, under the `migrate` subcommand. Only migration scripts between stable releases are included. For the current release, **0.39 «Launchpad»** and later migrations are supported.
+To smoothen the update to the latest stable release, the SDK includes a set of CLI commands for managing migrations between SDK versions, under the `migrate` subcommand. Only migration scripts between stable releases are included. For the current release, **0.42 «Stargate»** and later migrations are supported.
 
 ### What qualifies as a Stable Release Update (SRU)
 
@@ -58,43 +58,53 @@ To smoothen the update to the latest stable release, the SDK includes a set of C
     * 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.
-* New features that introduces API breakages (e.g. public functions removal/renaming).
+* Breaking changes in Protobuf definitions, as specified in [ADR-044](./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 that fall in the following categories do not require a **Stable Release Exception** to be granted to be included in a stable point-release:
+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**.
-* **Client application's code-breaking changes**, i.e. changes that prevent client applications to *build without modifications* to the client application's source code.
+* **Protobug-breaking changes**, as specified in [ADR-044](./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 `master`. It is, in general, not appropriate to release bug fixes for stable releases without first testing them in `master`. Please apply the label [0.42 «Stargate»](https://github.com/cosmos/cosmos-sdk/labels/0.42%20LTS%20%28Stargate%29) to the issue.
+1. Check that the bug is either fixed or not reproducible in `master`. It is, in general, not appropriate to release bug fixes for stable releases without first testing them in `master`. 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.42.x`) and the PR included in the point-release's respective milestone (e.g. `0.42.5`).
+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
 
@@ -129,5 +139,5 @@ Their responsibilites include:
 The Stable Release Managers are appointed by the Interchain Foundation. Currently residing Stable Release Managers:
 
 * @clevinson - Cory Levinson
-* @amaurym - Amaruy Martiny
+* @amaurym - Amaury Martiny
 * @robert-zaremba - Robert Zaremba