Git branching model on Open Source project

Question

We are developping on top of an Open Source project which use multiple versions branches:

Ex: master , 1.1 (lts), 1.2 , 1.3 (lts), 2.0 ....

We use in production the previous LTS in order to have most stable branch possible.

Our problem:

We are curently on 1.1 and have hundreds of commits. (unmerged upstream PR, or internal changes). We need to move to 1.3

There is a new version branch every 3 months. So this process must be as painless and efficient as possible

Possible solutions:

• Merging 1.1 into 1.3 . Since the two trees have a long diverging tree, i am not sure if it's the best approach
• Cherry picking our commits from 1.1 to 1.3 . Not sure it's the best idea, since we will have to cherry pick all theses commits from version to version.

Do you have any suggestions or recommendations ?

Thanks

Answer 1

Could you have a "staging" branch between master and the release branches that you sync more frequently?

See git flow where they call the staging branch develop: https://www.atlassian.com/git/tutorials/comparing-workflows#gitflow-workflow

Answer 2

After a little more than a year, and many releases, we ended up doing the following :

First, we avoid making changes to the repository by using better suited extension points available. This reduces by 90% the complexity of the merges.

When it's time to switch to a new branch, we are performing a cherry-pick of the previous branch changes on the new version.

This solution is working much better that expected initially. When conflicts occurs, they are easy to fix, and since most of our changes to this repository are also submitted via PR to the upstream project, the actual deltas are smaller and smaller with time.