imp

RELEASE_PROCESS.md

@@ -236,6 +236,10 @@ Those modules can be considered as part of the Cosmos SDK, but features and impr
 * When a module is supposed to be used in an app (e.g `x/` modules), due to the dependency on the SDK, tagging a new version of a module must be done from a Cosmos SDK release branch. A compatibility matrix must be provided in the `README.md` of that module with the corresponding versions.
 * Modules that import the SDK but do not need to be imported in an app (`e.g. cosmovisor`) must be released from the `main` branch and follow the process defined below.
 
+> [!IMPORTANT]  
+> A module depending on a non stabilized version of `github.com/cosmos/cosmos-sdk` (any version prior to the removal of baseapp, runtime, server) SHOULD NOT be tagged following semver.
+> For instance, modules are still using 0ver until the main `github.com/cosmos/cosmos-sdk` has stabilized.
+
 ### Modules that do not depend on the Cosmos SDK
 
 Modules that do not depend on the Cosmos SDK can be released at any time from the `main` branch of the Cosmos SDK repository.

docs/build/building-modules/00-intro.md

@@ -63,6 +63,8 @@ While there are no definitive guidelines for writing modules, here are some impo
 The SDK provides a set of APIs that a module can implement, and a set of services that a module can use.
 Those APIs are defined in the `cosmossdk.io/core/appmodule` package, and are used to defined the module capabilities, which is used by `runtime` during the wiring of the application. 
 
+Whenever possible, a module should strive to use only the core APIs (`cosmossdk.io/core`) and not import the `github.com/cosmos/cosmos-sdk` module. This makes modules reusable accross SDK versions and reduces the risk of breaking changes.
+
 Learn more about the core APIs for modules [here](../../learn/advanced/02-core.md).
 
 ## Main Components of Cosmos SDK Modules