[Propose] create release-0.4 branch

[weizhouapache]

/kind feature

Describe the solution you'd like

I suggest to create a new branch for v0.4.X releases, which will

• stay on cluster-api v1.2.X
• accepts bug fixes only
• support older k8s versions
• All PRs should pass unit tests.
• e2e tests are skipped due to e2e: fix "Failed to compile e2e" #242

The branch name can be "release-0.4" (same as cluster-api) or "stable-0.4". It will be used for 0.4.X releases, for example 0.4.10.

The main branch will then be the development branch, which will

• upgrade to latest dependencies, for example cluster-api v1.4.2
• support latest k8s versions
• accepts bug fixes (cherry-pick or merge forward from release-0.4 branch)
• improvements and new features
• All PRs should pass unit tests and e2e tests.

Once v0.5.0 is released, create a new branch "release-0.5"

Anything else you would like to add:
[Miscellaneous information that will assist in solving the issue.]

Environment:

• Cluster-api-provider-cloudstack version:
• Kubernetes version: (use kubectl version):
• OS (e.g. from /etc/os-release):

[weizhouapache]

what do you think ?
@rohityadavcloud @davidjumani @g-gaston @hrak

[hrak]

Yes, good idea. It's been a while since there was a release and there have been quite some changes. Would love to start working on CAPI 1.3.x or 1.4.x support, there are some features in 1.3.x that would really help us.

Helpful docs:

• Cluster API v1.2 compared to v1.3
• Cluster API v1.3 compared to v1.4

PR's i would like to still make it into 0.4.x:

#230
#235

Both PR's are in use in our own CAPI/CAPC environment for a while now without issues.

[g-gaston]

I like this

[rohityadavcloud]

Thanks for starting this @weizhouapache in a way you're proposing a branching/maintenance/governance model that's something we follow in the Apache CloudStack community (https://cloudstack.apache.org/bylaws.html, https://cwiki.apache.org/confluence/display/CLOUDSTACK/Releases).

If there is no objections from the OWNERS, I think CAPC can benefit from the same. Keeping branches as per your suggested branching-model would allow stakeholders to use/maintain a particular release, while free up the main branch for active development and support subsequent CAPI and k8s releases.

[chrisdoherty4]

I'm in favor.

I would start with the v0.5 release though. I don't think we're going to support v0.4 once v0.5 is out and we intend on releasing v0.5 very soon once we upgrade CAPI. If we can merge the PRs requested by @hrak I think we can release the final v0.4 release with a tag on main.

I haven't read the CloudStack release methodology so I'm hesitant to adopt that in full off the bat; perhaps we could start with the simple branching outlined in the OP. How do we feel about that?

[chrisdoherty4]

I don't have permissions on this repository yet, but I'd like to create some milestones so we can form a lose roadmap.

[chrisdoherty4]

I created #248 and #249. #248 describes the rationale.

CAPC v0.4 uses CAPI v1.2. To provide users with at least 1 CAPC release using CAPI 1.3, I'm proposing we do a v0.5 release that uses CAPI 1.3 before upgrading to CAPI 1.4.

What do people think?

[chrisdoherty4]

@weizhouapache had reservations on doing 1.3 so I closed the issue. We can jump straight to CAPI 1.4.

[davidjumani]

+1 as well. This is also the way CAPI works

[rohityadavcloud]

Hi @weizhouapache looks like there are no objections, do you want to create a branch and close this issue, but it seems main has already changed a lot since ths discussion

[g-gaston]

/assign

I just created a release-0.4 branch
Given our previous release candidates releases for v0.4.9, were tagged from main and the diff from the latest release candidate was only bug fixes and docs, I cut it from there

From now on, everything we want in the next v0.4.9 release will need to be backported (use cherry pick bot) to this branch since I will be cutting the tag from there

I also cut v0.4.9-rc7 if folks want to test it

This all follows the same pattern core capi follows

If there are concerns with this approach, feel free to recreate or open a new issue so we can discuss

/close