Hi Chris,
exactly! This was possible with the sonar.branch.target property.
Now there’s only the way via web api or Sonarqube web ui, but only for branches that already exist
(i.e. the problem of @markluebbehuesen in this thread).
When using pull requests or one setting for all branches, see workaround here
all is fine, but there are many projects that don’t use PRs and there are special cases where one
general reference branch for all branches is not sufficient.
Gilbert
When Sonar Team going to add sonar.branch.target property back?
the sooner the better 
But seriously, with a lot of votes for this feature request and a LOT of related postings this problem has gained enough attention from Sonarsource - see @Chris posting above.
I hope / wish there’s already a solution in the making.
Gilbert
Any idea when this issue will be resolved.
i’m no Sonarsourcer and have no glance when this will be implemented.
Hi all,
These will ship in 9.4 (E.T.A. 4 April):
Ann
Hi Ann,
great news 
though much more to write 
sonar.newCode.referenceBranch = length 33
sonar.branch.target = length 23
From the descriptions in Jira it seems to be not different from old sonar.branch.target
behaviour beside the name.
Gilbert
Thx, great news indeed!
sonar.newCode.referenceBranch = length 33
sonar.branch.target = length 23
what does this mean?
g,
Peter
He’s just saying it’s more typing to get the same effect.
Just consider the new, longer name a sop to our pride.
Ann
sonar.newCode.referenceBranch = length 33
sonar.branch.target = length 23
^^^ There is zero equivalence, according to Sonar documentation, for these two properties. Why would you misconstrue, and conflate this? Again, deprecating sonar.branch.target is the most inane, and unconsidered approach SonarQube could do for VERY large enterprise organizations, whom have created implementations based on their delivery model, and SonarQube’s properties. I will be advocating for another solution now. Even though I loved SonarQube over our bespoke, and costly implementation of Coverity, this deprecation of a very basic feature could potentially cost our organization millions. I’m still unsure why Sonar has removed such a simple way to generate a delta based on a branch to be integrated to. I’ve explained enough in my previous comments on this thread as to why this feature change will hurt us. So, we’re kind of stuck.
How is that a solution? It is not the same. Please elaborate on implementation? We just upgraded to 8.9.6, and are now facing serious consequences.
This is a singular case example. which may work in your implementation, however, I can pretty much guarantee that many organizations will not have this type of integration. Previously, sonar.branch.target was simple to implement, and ensured that new code was analyzed against a delta of the specified target branch in question, rather than a more generalized, and defined common base target branch (e.g. “master”). This implementation fails when it comes to maintenance releases.
Hi John,
We’ve recently added the possibility to set a reference branch depending on the branch you are working on.
The parameter is not the same because the management of branches changed since the time we had short-lived branches. Since SonarQube 8.1, the concept for branches was simplified: short-lived and long-lived branches are just branches. Also, choosing a branch as a reference is considered a way to define the New Code on your working branch.
Can you please explain your use case if this still does not answer your need?
Chris
Here is my case: We are a very large enterprise organization currently using SonarQube version 8.9.6 (recently upgraded from 7.9). I noticed that a critical aspect of our implementation was now missing, the sonar.branch.target property, after the upgrade. We have a monolithic codebase consisting of over 850 components/modules (550 are Java, 300+ are native), each one receiving their own project in SonarQube. We do have an integrated tool chain; however, our Sonar is integrated into our build architecture, and implemented via a custom ant solution (I’ll avoid all the details here, though). Since our organization is contracted to support maintenance releases for many major enterprise customers, we also need the ability to control how a given branch’s delta is derived against its relative integration branch (there is only one), or release branch (many). Because of this, we need a method to automate the setting of a newly defined reference branch at compile time, for each module/sonar project, we analyze. After doing more research, I was able to find that using the sonar.newCode.referenceBranch does seem to provide the necessary feature we need, by setting this property each time we would be able to compile a component in our code base (again, I’m not going into to much detail as I am refactoring this incredibly complex build architecture soon) and set the new code period for the “long lived” branch specified now as the reference branch; however, that property isn’t actually available unless we upgrade to at least version 9.4 (per documentation). Unfortunately, I don’t manage the upgrades, but I do have some sway in the solution our company goes with, because our internal org represents the largest profit generator there. Hope that helps you understand our case. In terms of the management of branches, after version 8.1, it seems that SonarQube made many assumptions of how very large organizations manage software releases, and maintenance; which I find to be wrong, in several enterprise cases. Unless, of course, a dev org only needs to be concerned with the newest release, always. In our case, we may have a release branch which currently can live on in perpetuity, thereby breaking this assumption.
By the way, we also have a group that creates a custom OS, which also follows a similar model, yet it is multi-repo based. When using Sonar 7.9, we also implemented the sonar.branch.target property for this group, as well.
Oh yes, one more thing. I should at least mention that when we moved from Coverity to SonarQube, I was one of the biggest proponents internally driving that. I love what SonarQube provided us at that time, relatively speaking.
Thanks for sharing John.
We try to make SonarQube friendly with the way of working in large organizations. I can understand your need and unfortunately, this new code definition is a major change that was added after the 8.9 LTS. Happy to read that the new configuration will meet your expectations.
It does, we just have to upgrade to the 9.4 version to get it, unfortunately. Do you happen to know if there is a maintenance release off of 8.X.X with this new feature?
Hi,
There’s not. The LTS isn’t updated for new features. Only significant bugs and vulnerabilities.
Ann
Hi,
we use Sonarqube Enterprise edition.
I’ve decided to go with the latest Sonarqube version in 2017 to be able to use the latest / new features.
Beside some problems with early 8.x versions we never faced any problems.
As now it ain’t possible to update language scanner plugins - i.e. Sonar Java - without updating your Sonarqube instance, it’s IMO mandatory to go with the latest Sonarqube version if you need to support the latest i.e. typescript/javascript … syntax.
As Enterprise customer since 2016 i recommend to go with the latest version instead of LTS (every 18 month) to use the most recent language scanner plugins.
Gilbert