wip: proposing a new release process

[leogr]

What type of PR is this?

/kind documentation

What this PR does / why we need it:

Dear @falcosecurity/libs-maintainers

This PR proposes a new structured but still streamlined release process which uses release branches and reduces the code freeze period as much as possible.

This idea was initially proposed by @jasondellaluce , discussed in various community calls, and experimented it during the Falco 0.32.2 release with the help of @Andreagit97 .

This PR is going further, proposing precise rules and phases.

Now, the proposal is to keep this PR as a wip and test drive the new process during the next libs release. In this way, we can directly incorporate any feedback from an authentic release experience and eventually merge this once the release is done.

:smiley:

Which issue(s) this PR fixes:

Fixes #

Special notes for your reviewer:

Does this PR introduce a user-facing change?:

NONE

[leogr]

cc'ing other folks I know might be interested @araujof @terylt @incertum :hugs:

[araujof]

Nice job, @leogr! 👍

I think that the new release process will simplify release management and testing, without freezing the main dev branch. Thanks for working on this!

[leogr]

/milestone 0.10.0

[terylt]

Hey Folks, nice work @leogr. My only comment is that if you want to avoid a code freeze, what you could do is have two main branches: main and dev. All new checkins and PRs go into the dev branch. When you are getting ready to cut a release, the dev branch gets merged into main and the main is tested, which acts as a code "freeze". Bug fixes etc can be done in main and a release tag created. Dev continues to be open to allow PRs to be added with no "freeze". main basically holds your releases and bug fixes to those releases. This takes away the urgency to unfreeze a branch and gives time to test. We've used this approach in the past and it works well. Just a thought.

Great work!

[leogr]

Hey Folks, nice work @leogr. My only comment is that if you want to avoid a code freeze, what you could do is have two main branches: main and dev. All new checkins and PRs go into the dev branch. When you are getting ready to cut a release, the dev branch gets merged into main and the main is tested, which acts as a code "freeze". Bug fixes etc can be done in main and a release tag created. Dev continues to be open to allow PRs to be added with no "freeze". main basically holds your releases and bug fixes to those releases. This takes away the urgency to unfreeze a branch and gives time to test. We've used this approach in the past and it works well. Just a thought.

Great work!

Hey @terylt

Thank you for your feedback :hugs:

Using the dev branch or most complex conventions like git-flow are alternatives we already evaluated but discarded because they looked more complicated and potentially required more cherry-picking in case of later discovered problems.

For example, if a significant issue is later discovered in the main branch, we would have needed to cherry-pick a complex patch back to the dev branch (which may have diverged significatively, meanwhile).

In our idea, the small freeze period should avoid the main branch, and the release branch would diverge too much. That should drastically reduce the likelihood of conflicts during cherry-pick operations.

Note: cherry-pick operations are a bit troublesome since our policy always requires protected branches and linear git history. This policy is implicit and inherited from K8s automation - Prow, that we call @poiana - which ensures that ownership is consistently enforced thru PR reviews. Basically, any cherry-pick will require a PR, and no merge commits are allowed. We can't just cherry-pick and push to a branch.

That being said, we are still experimenting, so any alternative strategy is still to be taken into consideration :smiley_cat:

[terylt]

Hey Folks, nice work @leogr. My only comment is that if you want to avoid a code freeze, what you could do is have two main branches: main and dev. All new checkins and PRs go into the dev branch. When you are getting ready to cut a release, the dev branch gets merged into main and the main is tested, which acts as a code "freeze". Bug fixes etc can be done in main and a release tag created. Dev continues to be open to allow PRs to be added with no "freeze". main basically holds your releases and bug fixes to those releases. This takes away the urgency to unfreeze a branch and gives time to test. We've used this approach in the past and it works well. Just a thought. Great work!

Hey @terylt

Thank you for your feedback 🤗

Using the dev branch or most complex conventions like git-flow are alternatives we already evaluated but discarded because they looked more complicated and potentially required more cherry-picking in case of later discovered problems.

For example, if a significant issue is later discovered in the main branch, we would have needed to cherry-pick a complex patch back to the dev branch (which may have diverged significatively, meanwhile).

In our idea, the small freeze period should avoid the main branch, and the release branch would diverge too much. That should drastically reduce the likelihood of conflicts during cherry-pick operations.

Note: cherry-pick operations are a bit troublesome since our policy always requires protected branches and linear git history. This policy is implicit and inherited from K8s automation - Prow, that we call @poiana - which ensures that ownership is consistently enforced thru PR reviews. Basically, any cherry-pick will require a PR, and no merge commits are allowed. We can't just cherry-pick and push to a branch.

That being said, we are still experimenting, so any alternative strategy is still to be taken into consideration 😺

I'll just make one last comment on the dev branch model. One of the really nice things about having a dev branch is that when you make a massive change to the code base, you can push that change to dev, and have release candidates in there, and "edge" cuts of the project. This allows the community at large to do more testing on major feature changes before they ever get into main. In the current model, those changes are either in PR or they are in main.

Anyway, nice work!

[leogr]

Quick update: applied some reviews suggestions from @incertum

Also, :thinking: I wonder if we should add such as warning :point_down:

[leogr]

Hey @falcosecurity/libs-maintainers

I believe it's time to bump this.

[leogr]

Closing and reopening to trigger the CI /close

[poiana]

@leogr: Closed this PR.

In response to this:

Closing and reopening to trigger the CI /close

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

[leogr]

/reopen

[poiana]

@leogr: Reopened this PR.

In response to this:

/reopen

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

[poiana]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: Andreagit97, FedeDP, leogr, LucaGuerra

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

• ~~OWNERS~~ [Andreagit97,FedeDP,LucaGuerra,leogr]

Approvers can indicate their approval by writing /approve in a comment Approvers can cancel approval by writing /approve cancel in a comment