Have branches per minor versions

[jlprat]

What can we help you with?

In order to better manage versioning in Karapace, it would be good to create a branch per each minor version (assuming semantic versioning) so creating hotfixes on those are easy to handle.

Where would you expect to find this information?

I would expect this is documented in the CONTRIBUTING, and in a new file named RELEASE.
Information about CONTRIBUTING would describe the meaning of such branches and also specify that Pull Request can be targeted to such branches if the bug is only present there or if the fix must be released also for that minor version.
The new file named RELEASE should incorporate all needed information and steps that must be followed for releasing a new Karapace version, one of them would be if this is agreed, to create a new branch once a new minor version is created.

For example at the time of writing the branches that should be present would be:

• 0.1.x
• 1.0.x
• 1.1.x
• 2.0.x

All community members are welcomed to share their opinion on this topic.

[jlprat]

Related: #245

[hackaugusto]

My proposal is to use https://githubflow.github.io/

[jlprat]

I agree we should be using the "github flow" for the PR flow.
However, when cutting releases, we might want to have branches per versions to be able to provide hotfixes and such. As pointed in the link you shared something closer to the "git flow" might be helpful for this, but this discussion might only happen after we reached a consensus on #245

[tvainika]

I'd say that create a branch for given version is also a soft promise for support and backporting fixes to that version. AFAIK no such backporting or support has been yet done for Karapace, and thus first the maintenance periods are to be decided. And only after maintenance period is defined, then create branches for only maintained versions.

[lornajane]

Could we switch to using a main branch and releasing from that as a first step? And I think a maintenance commitment would be excellent as well. That would pave the way for having multiple branches and a commitment to backporting once that comes into effect (I assume a new release is needed to start a timer on the old/existing one so this isn't instant)

[jlprat]

I agree with you @lornajane that would also be my proposal. main branch would be our baseline one. Once a new minor release is cut, and properly tagged, a branch for that one is created. This last bit is only interesting if, as you say, we want to offer a maintenance period for such releases (discussion happening in #245).

[jlprat]

This has been open for a while, as no further feedback has been provided it seems we reached an agreement to release from main and enabling us to branch out of tagged releases if fixes need to happen (discussion in #245.
I'm closing this one, if anybody has different opinion that hasn't been shared yet, please flag it so.