Module Upgrade Strategy

Module	Micronaut	Allowed
Patch	Patch	✅
Patch	Minor	✅
Patch	Major	✅
Minor	Patch	🚫 (1)
Minor	Minor	✅ (1)
Minor	Major	✅
Major	Patch	🚫
Major	Minor	🚫 or 🤔✅ (2)
Major	Major	✅

(1) If a module's dependency upgrades a minor version. E.g. Elastic search module has the elastic search dependency to upgrade from 7.8 to 7.9, the module should release a new minor version and that minor version will be included in the next minor Micronaut version but not in the next Micronaut's patch version. Patch version will never update users' production dependencies.

(2) If a module's dependency upgrades to a major version. A new major version of the module will be released. A major version of the module will be included in a minor version of Micronaut only if we are sure that the change will not introduce breaking changes in users apps.

A couple of examples:

• A module in version 1.0.3 was built with Micronaut 1.3.8. Micronaut 2.0.0 shipped with version 1.0.3 of that module. The module is upgraded to be built with Micronaut 2.x and since that it is major change a new version of the module 2.0.0 is released. Micronaut 2.1 can include that module.
• A transitive dependency of the module has a major upgrade but we have a deep knowledge about the dependency and we are sure it will not introduce breaking changes for the users. E.g. new GORM major release. We could release a new major version of the module and include it in a next Minor version of Micronaut. This should be used with extreme care since it is difficult to have confidence and good knowledge about a such major upgrade. In case of breaking changes, doubts or lack of knowledge release the module major version but don't include in the next Micronaut minor version.

We should check release notes of updated dependencies.