Do we need a release cycle in CAPA?

[richardcase]

In CAPA we do releases in an ad-hoc manor, as & when there is consensus among the maintainers that a release is needed.

Should CAPA adopt a more formal/prescribed release cycle? Especially as more people are starting to depend on CAPI/CAPA both from an end-user and commercial product perspective. Would a more formal release cycle enable our users to plan better?

For reference, CAPI has recently adopted a more formal Release Cycle. We could adopt something similar, our own version or stay with ad-hoc.

What do you think?

[Skarlso]

Absolutely agree. We should have some cadence. If not for a regular release, then for making it a repeatable, more or less, automated process instead of the manual steps that it needs now.

[Ankitasw]

IMHO, we don't need so many regular releases in CAPA as such(unless there is a bug that has to be fixed immediately), so we could stick to ad-hoc, but it would be good to have automated releases so as to remove dependency on maintainers.

[richardcase]

My concern with sticking with the ad-hoc approach is that it's very hard for our users to plan around CAPA. Especially for companies that use CAPI/CAPA as a core/foundational technology in their products.

If we don't adopt a release cycle, we should to at least define the criteria that will trigger a new release. And agree with the points made around improving automation.

[Ankitasw]

I think this makes sense to me, we could have some criteria set, but lets discuss more on how to do that 😅 coz i am quite new to this.

[richardcase]

I'll add it to the next office hours for discussion.

[pydctw]

I definitely think CAPA should have a defined release cycle. Watching 2.0.0 release prep, there were a lot of items that were rushed in the end.

Having a defined release cycle will make things go smoothly and also give people time to review code more thoroughly. As a reviewer who has other responsibilities, it is hard to follow CAPA daily-basis and plan when things happen ad-hoc.

[Skarlso]

The mentioned release cycle doc moved to here: https://github.com/kubernetes-sigs/cluster-api/blob/main/docs/release/release-cycle.md

[richardcase]

Let's think about the release cycle again. It would help us stay aligned with the CAPI version changes and provide consistency for planning for our users and people that build products/services on top of CAPI.

I'll add it to the next office hours for discussion.

[AndiDog]

We try to stick to stable releases if possible. If hotfixes are needed, we create custom releases. But I think that most companies would rather rely on official releases instead of building their own releases, images, etc. So @richardcase's verbal idea of a "minimum" cadence makes sense. If the manual effort is too high for you as maintainers, working out the automation first would help a lot to define at what interval the releases could then be pushed out.

[dlipovetsky]

For patch releases, I think regular, and quick cadence makes sense . Patches are mostly bug fixes, which have the greatest urgency.

For minor releases, a regular makes sense, too. If we have at least one feature pending, we make a minor release; if we have none, we delay it until the next interval.

For major releases, which are rare, I think ad-hoc still makes sense.

---

I think patch releases deserve the quickest cadence, and the project would therefore benefit the most from automating patch releases as much as possible.

I would prefer to avoid ad-hoc patch releases (also referred to as "hotfix" or "custom" patch releases).

[richardcase]

@yastij - do you have anything agreed on the CAPV side? I think i remember you saying there would be a release within 2 weeks of a CAPI release?