Bringing commits from previous branches into newer branches

[porunov]

I found out that after we enabled backporting features it is now harder to merge previous branches (v0.6 now) into newer branches (master).
Even with a single version update (single line change) we often receive quite a few conflicts to resolve which are not directly related to the changes introduced.

Moreover, after we merge previous branch into master branch we receive duplicate commits (any commit which was backported will be duplicated in master branch).

Not sure which development process is better, but I think if we want to continue using backport feature we should stop merging branches into branches. Instead, cherry pick commits when necessary.
By using cherry pick approach we could probably miss some commits in master branch when we have new commits in v0.6 because someone who merge a commit into v0.6 could forget bringing it into master branch. As we never merge v0.6 into master branch there is a chance that commit will never be ported into master branch.

I don't have a good solution or advice on this but I feel we should discuss this topic.

As for me we should stick to either of the approaches.

1. no backports but be able to merge branches into branches (i.e. TinkerPop like style, when all commits from behind branches are merged into master).
2. backports but no merges of branch into branch. Instead cherry picking when necessary (I.e. ElasticSearch style where old branches have many commits ahead and will never be merged. Thus these branches will always be both ahead and behind master branch).

We were using development process "1" for some time now. I'm good with using development process "2" as well.
That said, I wanted to double check with community what others think.

cc @FlorianHockmann , @farodin91

[farodin91]

I would like solution 2. I think it reduce the overhead of new committers. If we default backport and just decide for breaking changes to use not to back port, it would easier and more streamlined.

[porunov]

Agree. Let's stick to the solution 2 then.

[FlorianHockmann]

We only had a quick discussion about this on Discord, but we've decided there that we want to try out solution 2. @farodin91 has already configured Dependabot to handle this automatically for dependency updates and we've started using this strategy also for other PRs.
But we haven't yet updated the documentation or announced this strategy widely because I think we wanted to try it out first for some time.

I think backporting works nicely and brings two advantages:

1. For contributors, especially first-time contributors: They can simply open their PR against master which most already used to do as they weren't aware of our merging strategy. No need to ask them to retarget on a different branch any more.
2. For committers: No need to manually merge PRs into multiple release branches. We can simply merge a PR in the GitHub UI and let the backporting action take care of backporting PRs to the other release branches.

And yes, if we follow through with backporting (solution 2), then we shouldn't merge release branches any more, but instead use the backporting action / tool to backport contributions.

We just need to decide which contributions we want to backport: Everything that is non-breaking or only bug fixes and (non-breaking) dependency updates?
Consider for example this PR: #3346. That's a simple performance optimization which shouldn't break anything. So, do we also want that in v0.6 or not?

[porunov]

Agree. Let's stick to the solution 2 then.

We just need to decide which contributions we want to backport: Everything that is non-breaking or only bug fixes and (non-breaking) dependency updates?
Consider for example this PR: #3346. That's a simple performance optimization which shouldn't break anything. So, do we also want that in v0.6 or not?

It's a good question. I think sometimes backporting might be a challenge in case we had a good amount of refactoring already. I'm thinking that we should backport bug-fixes as a rule of thumb and regardless of the refactoring challenges, but for non-breaking changes I would say it should be optionally, depending on how difficult it is to resolve conflicts for that commit.
In case with #3346 I think we don't have many breaking changes there, so we could backport it.
That said, I don't have a good reason to stick with this solution. Thus, I'm good with other solutions as well.

[FlorianHockmann]

Sounds like a good approach to default to backport changes if they are non-breaking, but that we don't require it in all cases, so we can also skip backporting if it requires too much effort.
The main argument I see in favor of backporting also new features (including such performance improvements) is that we don't release from master as often as we do from other release branches, simply because we wait longer until we release a new major version than a new patch version (which we do from other release branches).

[porunov]

Regarding rare master releases. This could be a reason for solution 3 in #3374 (potentially). Nevertheless, back-porting non-breaking features makes sense to me.