Should branches start with "release" be short-lived or long-lived?

Hi there,

We are using Sonarqube Developer Edition Version 7.7, and have a question on branch strategy.

We are following git-flow approach in our projects, so we have a develop and a master branch. When we’re about to release, a release branch is cut from the develop branch. Any fixes on the release branch is done through pull requests from short-lived branches to the release branch. After the release is published to public, the release branch is merged to the develop and the master branches.

In setting up SonarQube for our projects, we were wondering if release branches should be set as long-lived branches or short-lived? By default any branches start with “release” is set to be long-lived but according to the SonarQube document on branches it seems like release branches meet the definition of short-lived branches.

I guess there’s no “correct” answer here. It can differ per team. However, in your case, it does seem that release continues to exist throughout the development cycle, right? It just “represents” different releases, and always represents the latest, upcoming release.

In the documentation, the example for short-living branches shows a “release branch” for a very specific release (security-fix-1254). This branch is short-lived, because once released, it won’t receive any updates anymore. A future security release might be called something like security-fix-1255.

In your case, you don’t discard release once a new version is released. You continue to use it for the next version. So, in this case, I’d say a long-living branch is correct. But again, you should go for what makes most sense to you and your workflow.