Modules default branch and branch name

[sdelamo]

We have started working on Micronaut Framework 5. Several modules now have a master branch targeting the next major. The master branch is the default branch for modules.

Why are we doing this? When working on the major release of Micronaut Framework 4, we kept the master for Micronaut Framework 3 and started using a different branch for the next major in parallel. This caused confusion and headaches in the Micronaut Framework 4 migration. Thus, currently we have many modules with master being the branch targeting the next major.

However, this is causing its set of problems with additional work to cherry-pick commits to previous branches or the potential for accidental release of major versions.

Thus, to avoid any confusion, I am proposing the following - aligning modules to core workflow:

• Removing the master branch in modules.
• Use semantic versioning for branch names. The patch version is an x. e.g., 4.6.x
• Set the default branch to the next minor of the module. The next minor version that will be part of the next minor of the framework

I think we are in a position to make this change. We don't need a master branch in modules anymore. I may be missing something. I think file-sync uses the default branch. Please correct me if I am missing something.

• We no longer commit to Micronaut core after a module release.
• Moreover, https://docs.micronaut.io has versioned links. Thus, we are no longer pointing to latest module documentation but the the version of the module documentation part of the BOM.

Why use the next minor of the module as the default branch? The next minor is the best candidate for a valid base for every PR. Most common PRs: Most Dependency upgrades, new features, and improvements can be merged into the branch pointing to the next minor. Choosing a default branch, which minimizes the work of changing base or merging up, makes our work easier. Only bug fixes would need to choose the previous patch.

Before releasing a new version, module maintainers would need to make sure to merge up the prior version.

@micronaut-projects/core-developers Thoughts?

[sdelamo]

As an example, in Micronaut Security:

• master will be renamed to 5.0.x
• default branch will be 4.7.x which will be included in Micronaut Framework 4.4.0 platform BOM.

[yawkat]

Long overdue :) Big +1

[alvarosanchez]

If I understood you correctly, what you are proposing is basically the same as with the last major release, but instead of master, using a named branch.

To me, the most important part is that the default branch needs to be the one for Micronaut 4 because there is where Renovate works and where contributors will send PRs. Once Micronaut 5 release is closer (say after summer), I'm ok with changing the default branch to the next major.

Regarding renaming master, I'm not sure if we still hardcode it somewhere, we would need to test this in a few repos first.

[wetted]

+1000

Like others I am working on micronaut 4 and 5. I get confused at times by what I need to point to when working mn4 PRs, and what to do with Renovate PRs.

[radovanradic]

Sounds good, I was also confused by trying to get renovate updates into micronaut-validation 4.6.0 (latest is currently 4.5.0) but those went to master so changes will be needed to be cherry picked. This looks way simpler.

[jeremyg484]

A definite +1 from me as well. I think the strategy we've been using in Core makes more sense to me and it's good to bring consistency to the other modules.