Fix for Evmos tests

.github/mergify.yml

@@ -0,0 +1,52 @@
+queue_rules:
+  - name: default
+    conditions:
+      - "#approved-reviews-by>=1"
+      - base=main
+      - label=automerge
+
+pull_request_rules:
+  - name: automerge to main with label automerge and branch protection passing
+    conditions:
+      - "#approved-reviews-by>=1"
+      - base=main
+      - label=automerge
+    actions:
+      queue:
+        name: default
+        method: squash
+        commit_message_template: |
+           {{ title }} (#{{ number }})
+           {{ body }}
+  - name: backport patches to v1.1.x branch
+    conditions:
+      - base=main
+      - label=backport-to-v1.1.x
+    actions:
+      backport:
+        branches:
+          - release/v1.1.x
+  - name: backport patches to v1.2x branch
+    conditions:
+      - base=main
+      - label=backport-to-v1.2.x
+    actions:
+      backport:
+        branches:
+          - release/v1.2.x
+  - name: backport patches to v2.0.x branch
+    conditions:
+      - base=main
+      - label=backport-to-v2.0.x
+    actions:
+      backport:
+        branches:
+          - release/v2.0.x
+  - name: backport patches to v3.0.x branch
+    conditions:
+      - base=main
+      - label=backport-to-v3.0.x
+    actions:
+      backport:
+        branches:
+          - release/v3.0.x

.github/workflows/check-docs.yml

@@ -0,0 +1,26 @@
+name: Check docs build
+# This workflow runs when a PR is labeled with `docs`
+# This will check if the docs build successfully by running `npm run build`
+on:
+  pull_request:
+  paths:
+      - './docs'
+
+jobs:
+  check-docs-build:
+    if: ${{ github.event.label.name == 'docs' }}
+
+    name: Check docs build
+    runs-on: ubuntu-latest
+    steps:
+      - name: Checkout 🛎️
+        uses: actions/[email protected]
+        with:
+          persist-credentials: false
+          fetch-depth: 0
+
+      - name: Install dependencies and build docs 🧱
+        run: |
+          cd docs
+          npm install
+          npm run build

.github/workflows/link-check.yml

@@ -4,7 +4,7 @@ jobs:
   markdown-link-check:
     runs-on: ubuntu-latest
     steps:
-    - uses: actions/checkout@v2
+    - uses: actions/checkout@v2.4.0
     - uses: gaurav-nelson/github-action-markdown-link-check@v1
       with:
         config-file: '.github/workflows/link-check-config.json'

.github/workflows/test.yml

@@ -18,7 +18,7 @@ jobs:
   install-tparse:
     runs-on: ubuntu-latest
     steps:
-      - uses: actions/[email protected].4
+      - uses: actions/[email protected].5
         with:
           go-version: 1.17
       - name: Display go version
@@ -37,8 +37,8 @@ jobs:
       matrix:
         go-arch: ["amd64", "arm", "arm64"]
     steps:
-      - uses: actions/checkout@v2.3.4
-      - uses: actions/[email protected].4
+      - uses: actions/checkout@v2.4.0
+      - uses: actions/[email protected].5
         with:
           go-version: 1.17
       - uses: technote-space/get-diff-action@v5
@@ -54,7 +54,7 @@ jobs:
   split-test-files:
     runs-on: ubuntu-latest
     steps:
-      - uses: actions/checkout@v2.3.4
+      - uses: actions/checkout@v2.4.0
       - name: Create a file with all the pkgs
         run: go list ./... > pkgs.txt
       - name: Split pkgs into 4 files
@@ -85,8 +85,8 @@ jobs:
       matrix:
         part: ["00", "01", "02", "03"]
     steps:
-      - uses: actions/checkout@v2.3.4
-      - uses: actions/[email protected].4
+      - uses: actions/checkout@v2.4.0
+      - uses: actions/[email protected].5
         with:
           go-version: 1.17
       - uses: technote-space/get-diff-action@v5
@@ -112,7 +112,7 @@ jobs:
     runs-on: ubuntu-latest
     needs: tests
     steps:
-      - uses: actions/checkout@v2.3.4
+      - uses: actions/checkout@v2.4.0
       - uses: technote-space/get-diff-action@v5
         with:
           PATTERNS: |

CHANGELOG.md

@@ -42,6 +42,8 @@ Ref: https://keepachangelog.com/en/1.0.0/
 
 ### API Breaking
 
+* (transfer) [\#675](https://github.com/cosmos/ibc-go/pull/675) Transfer `NewKeeper` now takes in an ICS4Wrapper. The ICS4Wrapper may be the IBC Channel Keeper when ICS20 is not used in a middleware stack. The ICS4Wrapper is required for applications wishing to connect middleware to ICS20.
+* (core) [\#650](https://github.com/cosmos/ibc-go/pull/650) Modify `OnChanOpenTry` IBC application module callback to return the negotiated app version. The version passed into the `MsgChanOpenTry` has been deprecated and will be ignored by core IBC.
 * (core) [\#629](https://github.com/cosmos/ibc-go/pull/629) Removes the `GetProofSpecs` from the ClientState interface. This function was previously unused by core IBC.
 * (transfer) [\#517](https://github.com/cosmos/ibc-go/pull/517) Separates the ICS 26 callback functions from `AppModule` into a new type `IBCModule` for ICS 20 transfer.
 * (modules/core/02-client) [\#536](https://github.com/cosmos/ibc-go/pull/536) `GetSelfConsensusState` return type changed from bool to error.
@@ -54,6 +56,7 @@ Ref: https://keepachangelog.com/en/1.0.0/
 * [\#383](https://github.com/cosmos/ibc-go/pull/383) Adds helper functions for merging and splitting middleware versions from the underlying app version.
 * (modules/core/05-port) [\#288](https://github.com/cosmos/ibc-go/issues/288) Making the 05-port keeper function IsBound public. The IsBound function checks if the provided portID is already binded to a module.
 * (channel) [\#644](https://github.com/cosmos/ibc-go/pull/644) Adds `GetChannelConnection` to the ChannelKeeper. This function returns the connectionID and connection state associated with a channel. 
+* (channel) [\647](https://github.com/cosmos/ibc-go/pull/647) Reorganizes channel handshake handling to set channel state after IBC application callbacks. 
 
 ### Features
 

Makefile

@@ -196,11 +196,13 @@ godocs:
 build-docs:
 	@cd docs && \
 	while read -r branch path_prefix; do \
-		(git checkout $${branch} && npm install && VUEPRESS_BASE="/$${path_prefix}/" npm run build) ; \
+		echo "building branch $${branch}" ; \
+		(git clean -fdx && git reset --hard && git checkout $${branch} && npm install && VUEPRESS_BASE="/$${path_prefix}/" npm run build) ; \
 		mkdir -p ~/output/$${path_prefix} ; \
 		cp -r .vuepress/dist/* ~/output/$${path_prefix}/ ; \
 		cp ~/output/$${path_prefix}/index.html ~/output ; \
 	done < versions ;
+
 .PHONY: build-docs
 
 ###############################################################################

docs/app_modules/interchain-accounts/overview.md

@@ -2,4 +2,31 @@
 order: 1
 -->
 
+# Overview
+
+Learn about what the Interchain Accounts module is, and how to build custom modules that utilize Interchain Accounts functionality {synopsis}
+
+
+# What is the Interchain Accounts module?
+
+Interchain Accounts is the Cosmos SDK implementation of the ICS-27 protocol, which enables cross-chain account management built upon IBC. Chains using the Interchain Accounts module can programmatically create accounts on other chains and control these accounts via IBC transactions. 
+
+Interchain Accounts exposes a simple-to-use API which means IBC application developers do not require an in-depth knowledge of the underlying low-level details of IBC or the ICS-27 protocol. 
+
+Developers looking to build upon Interchain Accounts must write custom logic in their own IBC application module, called authentication modules.
+
+- How is an interchain account different than a regular account?
+
+Regular accounts use a private key to sign transactions on-chain. Interchain Accounts are instead controlled programmatically by separate chains via IBC transactions. Interchain Accounts are implemented as sub-accounts of the interchain accounts module account. 
+
+# Concepts 
+
+*Host Chain*: The chain where the interchain account is registered. The host chain listens for IBC packets from a controller chain which should contain instructions (e.g. cosmos SDK messages) for which the interchain account will execute.
+
+*Controller Chain*: The chain registering and controlling an account on a host chain. The controller chain sends IBC packets to the host chain to control the account. A controller chain must have at least one interchain accounts authentication module in order to act as a controller chain. 
+
+*Authentication Module*: A custom IBC application module on the controller chain that uses the Interchain Accounts module API to build custom logic for the creation & management of interchain accounts. For a controller chain to utilize the interchain accounts module functionality, an authentication module is required.
+
+*Interchain Account*: An account on a host chain. An interchain account has all the capabilities of a normal account. However, rather than signing transactions with a private key, a controller chain's authentication module will send IBC packets to the host chain which signals what transactions the interchain account should execute.
+
 

docs/ibc/apps.md

@@ -71,9 +71,8 @@ OnChanOpenTry(
     channelID string,
     channelCap *capabilitytypes.Capability,
     counterparty channeltypes.Counterparty,
-    version,
     counterpartyVersion string,
-) error {
+) (string, error) {
     // Module may have already claimed capability in OnChanOpenInit in the case of crossing hellos
     // (ie chainA and chainB both call ChanOpenInit before one of them calls ChanOpenTry)
     // If the module can already authenticate the capability then the module already owns it so we don't need to claim
@@ -88,8 +87,18 @@ OnChanOpenTry(
     // ... do custom initialization logic
 
     // Use above arguments to determine if we want to abort handshake
-    err := checkArguments(args)
-    return err
+    if err := checkArguments(args); err != nil {
+        return err
+    }
+
+    // Construct application version 
+    // IBC applications must return the appropriate application version
+    // This can be a simple string or it can be a complex version constructed
+    // from the counterpartyVersion and other arguments. 
+    // The version returned will be the channel version used for both channel ends. 
+    appVersion := negotiateAppVersion(counterpartyVersion, args)
+
+    return appVersion, nil
 }
 
 // Called by IBC Handler on MsgOpenAck
@@ -157,38 +166,11 @@ OnChanCloseConfirm(
 Application modules are expected to verify versioning used during the channel handshake procedure.
 
 * `ChanOpenInit` callback should verify that the `MsgChanOpenInit.Version` is valid
-* `ChanOpenTry` callback should verify that the `MsgChanOpenTry.Version` is valid and that `MsgChanOpenTry.CounterpartyVersion` is valid.
+* `ChanOpenTry` callback should construct the application version used for both channel ends. If no application version can be constructed, it must return an error. 
 * `ChanOpenAck` callback should verify that the `MsgChanOpenAck.CounterpartyVersion` is valid and supported.
 
-IBC expects application modules to implement the `NegotiateAppVersion` method from the `IBCModule`
-interface. This method performs application version negotiation and returns the negotiated version.
-If the version cannot be negotiated, an error should be returned.
-
-```go
-// NegotiateAppVersion performs application version negotiation given the provided channel ordering, connectionID, portID, counterparty and proposed version.
-// An error is returned if version negotiation cannot be performed. For example, an application module implementing this interface
-// may decide to return an error in the event of the proposed version being incompatible with it's own
-NegotiateAppVersion(
-    ctx sdk.Context,
-    order channeltypes.Order,
-    connectionID string,
-    portID string,
-    counterparty channeltypes.Counterparty,
-    proposedVersion string,
-) (version string, err error) {
-    // do custom application version negotiation logic
-}
-```
-
-This function `NegotiateAppVersion` returns the version to be used in the `ChanOpenTry` step
-(`MsgChanOpenTry.Version`). The relayer chooses the initial version in the `ChanOpenInit` step
-(this will likely be chosen by the user controlling the relayer or by the application that
-triggers the `ChanOpenInit` step).
-
-The version submitted in the `ChanOpenInit` step (`MsgChanOpenInit.Version`) is passed as an
-argument (`proposedVersion`) to the function `NegotiateAppVersion`. This function looks at
-the `proposedVersion` and returns the matching version to be used in the `ChanOpenTry` step.
-Applications can choose to implement this in however fashion they choose.
+IBC expects application modules to perform application version negotiation in `OnChanOpenTry`. The negotiated version
+must be returned to core IBC. If the version cannot be negotiated, an error should be returned.
 
 Versions must be strings but can implement any versioning structure. If your application plans to
 have linear releases then semantic versioning is recommended. If your application plans to release

modules/core/spec/06_events.md → docs/ibc/events.md

@@ -1,9 +1,11 @@
 <!--
-order: 6
+order: 5
 -->
 
 # Events
 
+**NOTE**: This document is unmaintained and may be out of date!
+
 The IBC module emits the following events. It can be expected that the type `message`,
 with an attirbute key of `action` will represent the first event for each message
 being processed as emitted by the SDK's baseapp. Each IBC TAO message will

docs/ibc/middleware/develop.md

@@ -103,29 +103,32 @@ func OnChanOpenTry(
     channelID string,
     channelCap *capabilitytypes.Capability,
     counterparty channeltypes.Counterparty,
-    version,
     counterpartyVersion string,
-) error {
-      // core/04-channel/types contains a helper function to split middleware and underlying app version
-      cpMiddlewareVersion, cpAppVersion = channeltypes.SplitChannelVersion(counterpartyVersion)
-      middlewareVersion, appVersion = channeltypes.SplitChannelVersion(version)
-      if !isCompatible(cpMiddlewareVersion, middlewareVersion) {
-          return error
-      }
-      doCustomLogic()
-
-      // call the underlying applications OnChanOpenTry callback
-      app.OnChanOpenTry(
-          ctx,
-          order,
-          connectionHops,
-          portID,
-          channelID,
-          channelCap,
-          counterparty,
-          cpAppVersion, // note we only pass counterparty app version here
-          appVersion, // only pass app version
-      )
+) (string, error) {
+    doCustomLogic()
+
+    // core/04-channel/types contains a helper function to split middleware and underlying app version
+    cpMiddlewareVersion, cpAppVersion = channeltypes.SplitChannelVersion(counterpartyVersion)
+
+    // call the underlying applications OnChanOpenTry callback
+    appVersion, err := app.OnChanOpenTry(
+        ctx,
+        order,
+        connectionHops,
+        portID,
+        channelID,
+        channelCap,
+        counterparty,
+        cpAppVersion, // note we only pass counterparty app version here
+    )
+    if err != nil {
+        return err
+    }
+
+    middlewareVersion := negotiateMiddlewareVersion(cpMiddlewareVersion)
+    version := constructVersion(middlewareVersion, appVersion)
+
+    return version
 }
 
 func OnChanOpenAck(
@@ -134,15 +137,15 @@ func OnChanOpenAck(
     channelID string,
     counterpartyVersion string,
 ) error {
-      // core/04-channel/types contains a helper function to split middleware and underlying app version
-      middlewareVersion, appVersion = channeltypes.SplitChannelVersion(version)
-      if !isCompatible(middlewareVersion) {
-          return error
-      }
-      doCustomLogic()
+    // core/04-channel/types contains a helper function to split middleware and underlying app version
+    middlewareVersion, appVersion = channeltypes.SplitChannelVersion(version)
+    if !isCompatible(middlewareVersion) {
+        return error
+    }
+    doCustomLogic()
 
-      // call the underlying applications OnChanOpenTry callback
-      app.OnChanOpenAck(ctx, portID, channelID, appVersion)
+    // call the underlying applications OnChanOpenTry callback
+    app.OnChanOpenAck(ctx, portID, channelID, appVersion)
 }
 
 func OnChanOpenConfirm(
@@ -236,4 +239,4 @@ func SendPacket(appPacket channeltypes.Packet) {
 
     return ics4Keeper.SendPacket(packet)
 }
-```
+```