fix: documenation for client refactor

docs/architecture/adr-002-go-module-versioning.md

@@ -23,7 +23,7 @@ v1.0.0 was decided to be used instead of v0.1.0 primarily for the following reas
 
 When a Go module is released under v1.0.0, all following releases must follow Go semantic versioning.
 Thus when the go API is broken, the Go module major version **must** be incremented. 
-For example, changing the go package version from `v2` to `v3` bumps the import from `github.com/cosmos/ibc-go/v2` to `github.com/cosmos/ibc-go/v5`.
+For example, changing the go package version from `v2` to `v3` bumps the import from `github.com/cosmos/ibc-go/v2` to `github.com/cosmos/ibc-go/v3`.
 
 If the Go module version is not incremented then attempting to go get a module @v3.0.0 without the suffix results in:
 `invalid version: module contains a go.mod file, so major version must be compatible: should be v0 or v1, not v3`
@@ -33,7 +33,7 @@ Not including a go.mod in our release is not a viable option.
 
 #### Attempting to import multiple go module versions for ibc-go
 
-Attempting to import two versions of ibc-go, such as `github.com/cosmos/ibc-go/v2` and `github.com/cosmos/ibc-go/v5`, will result in multiple issues. 
+Attempting to import two versions of ibc-go, such as `github.com/cosmos/ibc-go/v2` and `github.com/cosmos/ibc-go/v3`, will result in multiple issues. 
 
 The Cosmos SDK does global registration of error and governance proposal types. 
 The errors and proposals used in ibc-go would need to now register their naming based on the go module version.
@@ -76,7 +76,7 @@ For example, lets say this solution is implemented in v3. Then
 
 `github.com/cosmos/ibc-go/v2` cannot be imported with any other ibc-go version
 
-`github.com/cosmos/ibc-go/v5` cannot be imported with any previous ibc-go versions
+`github.com/cosmos/ibc-go/v3` cannot be imported with any previous ibc-go versions
 
 `github.com/cosmos/ibc-go/v4` may be imported with ibc-go versions v3+
 

docs/migrations/v4-to-v5.md → docs/migrations/v5-to-v6.md

@@ -1,4 +1,4 @@
-# Migrating from ibc-go v4 to v5
+# Migrating from ibc-go v5 to v6
 
 This document is intended to highlight significant changes which may require more information than presented in the CHANGELOG.
 Any changes that must be done by a user of ibc-go should be documented here.
@@ -60,12 +60,12 @@ The `GetRoot` function has been removed from consensus state interface since it
 The `09-localhost` light client implementation has been removed because it is currently non-functional.
 
 An upgrade handler has been added to supply chain developers with the logic needed to prune the ibc client store and successfully complete the removal of `09-localhost`.
-Add the following to the application upgrade handler in `app/app.go`, calling `MigrateToV5` to perform store migration logic.
+Add the following to the application upgrade handler in `app/app.go`, calling `MigrateToV6` to perform store migration logic.
 
 ```go
 import (
     // ...
-    ibcv5 "github.com/cosmos/ibc-go/v5/modules/core/migrations/v5"
+    ibcv6 "github.com/cosmos/ibc-go/v6/modules/core/migrations/v6"
 )
 
 // ...
@@ -74,7 +74,7 @@ app.UpgradeKeeper.SetUpgradeHandler(
     upgradeName,
     func(ctx sdk.Context, _ upgradetypes.Plan, _ module.VersionMap) (module.VersionMap, error) {
         // prune the 09-localhost client from the ibc client store
-        ibcv5.MigrateToV5(ctx, app.IBCKeeper.ClientKeeper)
+        ibcv6.MigrateToV6(ctx, app.IBCKeeper.ClientKeeper)
 
         return app.mm.RunMigrations(ctx, app.configurator, fromVM)
     },

docs/roadmap/roadmap.md

@@ -14,7 +14,7 @@ This roadmap should be read as a high-level guide, rather than a commitment to s
 
 At a high level we will focus on:
 
-At a high level we will focus on:
+### Features
 
 - Releasing [v4.0.0](https://github.com/cosmos/ibc-go/milestone/26), which includes the ICS-29 Fee Middleware module.
 - Finishing and releasing the [refactoring of 02-client](https://github.com/cosmos/ibc-go/milestone/16). This refactor will make the development of light clients easier.