docs: rename app v2 to app di when talking about runtime v0 (backport #21329) (#21335)

Co-authored-by: Julien Robert <julien@rbrt.fr>

UPGRADING.md

@@ -72,7 +72,7 @@ for more info.
 A `SetPreBlocker` method has been added to BaseApp. This is essential for BaseApp to run `PreBlock` which runs before begin blocker other modules, and allows to modify consensus parameters, and the changes are visible to the following state machine logics.
 Read more about other use cases [here](https://github.com/cosmos/cosmos-sdk/blob/main/docs/architecture/adr-068-preblock.md).
 
-`depinject` / app v2 users need to add `x/upgrade` in their `app_config.go` / `app.yml`:
+`depinject` / app di users need to add `x/upgrade` in their `app_config.go` / `app.yml`:
 
 ```diff
 + PreBlockers: []string{
@@ -180,7 +180,7 @@ The following modules `NewKeeper` function now take a `KVStoreService` instead o
 * `x/slashing`
 * `x/upgrade`
 
-**Users using `depinject` / app v2 do not need any changes, this is abstracted for them.**
+**Users using `depinject` / app di do not need any changes, this is abstracted for them.**
 
 Users manually wiring their chain need to use the `runtime.NewKVStoreService` method to create a `KVStoreService` from a `StoreKey`:
 
@@ -197,7 +197,7 @@ app.ConsensusParamsKeeper = consensusparamkeeper.NewKeeper(
 
 Replace all your CometBFT logger imports by `cosmossdk.io/log`.
 
-Additionally, `depinject` / app v2 users must now supply a logger through the main `depinject.Supply` function instead of passing it to `appBuilder.Build`.
+Additionally, `depinject` / app di users must now supply a logger through the main `depinject.Supply` function instead of passing it to `appBuilder.Build`.
 
 ```diff
 appConfig = depinject.Configs(
@@ -221,7 +221,7 @@ User manually wiring their chain need to add the logger argument when creating t
 Previously, the `ModuleBasics` was a global variable that was used to register all modules' `AppModuleBasic` implementation.
 The global variable has been removed and the basic module manager can be now created from the module manager.
 
-This is automatically done for `depinject` / app v2 users, however for supplying different app module implementation, pass them via `depinject.Supply` in the main `AppConfig` (`app_config.go`):
+This is automatically done for `depinject` / app di users, however for supplying different app module implementation, pass them via `depinject.Supply` in the main `AppConfig` (`app_config.go`):
 
 ```go
 depinject.Supply(
@@ -332,7 +332,7 @@ When using (legacy) application wiring, the following must be added to `app.go`
 	app.txConfig = txConfig
 ```
 
-When using `depinject` / `app v2`, **it's enabled by default** if there's a bank keeper present.
+When using `depinject` / `app di`, **it's enabled by default** if there's a bank keeper present.
 
 And in the application client (usually `root.go`):
 
@@ -351,7 +351,7 @@ And in the application client (usually `root.go`):
 	}
 ```
 
-When using `depinject` / `app v2`, the a tx config should be recreated from the `txConfigOpts` to use `NewGRPCCoinMetadataQueryFn` instead of depending on the bank keeper (that is used in the server).
+When using `depinject` / `app di`, the a tx config should be recreated from the `txConfigOpts` to use `NewGRPCCoinMetadataQueryFn` instead of depending on the bank keeper (that is used in the server).
 
 To learn more see the [docs](https://docs.cosmos.network/main/learn/advanced/transactions#sign_mode_textual) and the [ADR-050](https://docs.cosmos.network/main/build/architecture/adr-050-sign-mode-textual).
 

client/v2/README.md

@@ -38,7 +38,7 @@ Here are the steps to use AutoCLI:
 
 1. Ensure your app's modules implements the `appmodule.AppModule` interface.
 2. (optional) Configure how behave `autocli` command generation, by implementing the `func (am AppModule) AutoCLIOptions() *autocliv1.ModuleOptions` method on the module.
-3. Use the `autocli.AppOptions` struct to specify the modules you defined. If you are using `depinject` / app v2, it can automatically create an instance of `autocli.AppOptions` based on your app's configuration.
+3. Use the `autocli.AppOptions` struct to specify the modules you defined. If you are using `depinject`, it can automatically create an instance of `autocli.AppOptions` based on your app's configuration.
 4. Use the `EnhanceRootCommand()` method provided by `autocli` to add the CLI commands for the specified modules to your root command.
 
 :::tip

docs/docs/build/building-apps/03-app-upgrade.md

@@ -53,7 +53,7 @@ be a matter of minutes and not even require them to be awake at that time.
 ## Integrating With An App
 
 :::tip
-The following is not required for users using `depinject` / app v2, this is abstracted for them.
+The following is not required for users using `depinject`, this is abstracted for them.
 :::
 
 In addition to basic module wiring, setup the upgrade Keeper for the app and then define a `PreBlocker` that calls the upgrade

docs/docs/build/building-modules/01-module-manager.md

@@ -319,7 +319,7 @@ Here's an example of a concrete integration within an `simapp`:
 https://github.com/cosmos/cosmos-sdk/blob/v0.50.0-alpha.0/simapp/app.go#L411-L434
 ```
 
-This is the same example from `runtime` (the package that powers app v2):
+This is the same example from `runtime` (the package that powers app di):
 
 ```go reference
 https://github.com/cosmos/cosmos-sdk/blob/v0.50.0-alpha.0/runtime/module.go#L61

simapp/app_test.go

@@ -53,7 +53,7 @@ func TestSimAppExportAndBlockedAddrs(t *testing.T) {
 		AppOpts: simtestutil.NewAppOptionsWithFlagHome(t.TempDir()),
 	})
 
-	// BlockedAddresses returns a map of addresses in app v1 and a map of modules name in app v2.
+	// BlockedAddresses returns a map of addresses in app v1 and a map of modules name in app di.
 	for acc := range BlockedAddresses() {
 		var addr sdk.AccAddress
 		if modAddr, err := sdk.AccAddressFromBech32(acc); err == nil {