proposal: get rid of develop branch

[tbruyelle]

The dual master/develop branch pattern adds some maintenance cost when we need to synchronize master and develop. Sometimes this even requires an extra synchronization branch to avoid conflicts (see #2928)

In addition, this maintenance must be done for each release.

With this proposal, I would like to open discussions for removing the develop branch, in favor of a single master branch.

TLDR

this proposal basically changes the need for maintenance from :

• having to do it for all releases
  to
• having to do it only when we patched a release.

Some key points

• Features branch would be based on master and merged to master when they are ready.
• Major and minor tags are created on master, as they should be (today most of them are created on develop, so I wonder what master is even for!)
• When we need to patch a release, we create a release branch on the related tag (for instance release/v0.24.x on v0.24.0 tag). The PR that contains the patch is based on this release branch. Once the PR is merged, a patch tag is created (v0.24.1) on the release branch, and the new binaries are built from there.
  The release branches are back ported to master eventually, by merging the release branch to master or by cherry-picking the commits. This time the maintenance happens only when we have to patch a release, and not for all releases.
  What could happen also when we need to fix a release, is to first fix the bug on master (so for the future release), and the commit is then cherry-picked in the release branch.

I add a small schema to summarize :

Voila, please give me your opinion, ask questions... 🙏

[aljo242]

@ilgooz @lubtd thoughts? I'm onboard with this

[lumtis]

I''m in as well, and doing the same for spn

[aljo242]

@tbruyelle is there a more detailed document about this branching style, comparing it to GitFlow (what we are using now)?

[tbruyelle]

@aljo242 This flow is inspired by the well known github flow, with additional rules for when we need to fix an existing release while development of the future release has already started.

[aljo242]

@ilgooz ^^^

[aljo242]

@albttx what do you think?

[albttx]

I'm 100% ok with this.

the current strategie (something close to git flow ) does have issues.

I feel that a much simpler solution can be used:

github-flow

• We create branches from master to develop features, and merge them into master
• We use git tags for releases

Some nice docs about

• https://medium.com/@patrickporto/4-branching-workflows-for-git-30d0aaee7bf
• http://scottchacon.com/2011/08/31/github-flow.html