prepare for branching v0.1

[kaworu]

For context, #220 will introduce a configuration breaking change and after discussion we will maintain patch release v0.1 branch for Cilium < v1.16.

.github/workflows/build-images-release.yaml is based on tags and thus should work without modifications. I'm also inclined to change the default branch to main instead of the current master for consistency with other cilium repository (see cilium/cilium#23110).

[giorio94]

Thanks!

[rolinh]

Why do we want to maintain a v0.1 branch with patch releases vs updating to v0.2 in stable branches of Cilium? What are our main concerns?

I'm wary of adding more maintenance work to our shoulders. Admittedly, updating the Cilium charts to use v0.2 is a one time effort that we can backport to stable branches whereas maintaining and publishing new releases for 2 branches is work that will have to be carried out until v1.15 is EOL.

[giorio94]

Why do we want to maintain a v0.1 branch with patch releases vs updating to v0.2 in stable branches of Cilium? What are our main concerns?

From my point of view, the main concern would be the possible introduction of regressions, mainly during the backport of the helm changes to stable branches. Different branches have slight differences, and CI coverage is a bit lacking in that respect AFAIK (I've recently modified the clustermesh tests to also leverage certgen, but for instance I don't think we validate the hubble certs anywhere explicitly in those workflows -- especially relay/ui ones).

[kaworu]

Why do we want to maintain a v0.1 branch with patch releases vs updating to v0.2 in stable branches of Cilium? What are our main concerns?

As @giorio94 pointed out regression is the main concern, but also it's unclear to me whether the overhead of maintaining v0.1 will be that much higher than porting v0.2 to stables branches.

[rolinh]

OK, let's go for it then.