We were having a conversation today, my coworkers and I, about the SonarQube version meaning. And we were unable to understand the purpose of the 4th digit, like in the latest Community Build.
25.3.0.104237
We had a look at the version history of every SonarQube flavor, and it appears that there can’t exist two versions A.B.C with a different fourth digit D.
Practically, there can’t exist 25.3.0.104237 and 25.3.0.104238. Everytime the fourth digit changes, it means that at least one of the three others also changed.
Hence, our questions:
Can it happen that both A.B.C.X and A.B.C.Y exist? If so, in what situation?
Isn’t the fourth digit just a public exposition of your internal build number, that has no purpose and no meaning in the final public release? If so, why not removing it entirely from the public release version and just keep the three first digits, that are actually meaningful?
Cheers,
Philippe.
EDIT: I’m conscious that I did not give the context why the discussion happened, and why it is meaningful to us. I don’t want to pollute that first post with, maybe, uninteresting information. Don’t hesitate to ask if you are interested.
We started attaching the build number to releases of SonarQube (all distributions, from Community to Data Center) with SonarQube v8.1 back in December 2019. All of the history around that decision is in this public Jira ticket (SONAR-12665).
Thank you. From what I read there, the fourth digit was added only to easy your release process. I won’t debate that, this is internal to your processes.
My question is why this 4th digit is displayed to the public? What does it bring to us? Is there a possibility that A.B.C.X and A.B.C.Y exist publicly?
To make my question more factual: do we need to give this 4th number to your support, or is A.B.C enough to identify the version with certainty?
And, sorry, I can’t resist to comment on this:
As a consequence, we make a specific commit to master to change the version, build that commit (and create released artifacts from there) and right after that push another commit to get back to normal.
SonarQube is handled by Gradle. There is no need to change anything in the project to build an arbitrary version. It is just a matter on passing some parameters to the build command - this has always been the case, same with Maven.
I really hope that the change to 4 digits was not driven by what I’m reading in the Jira issue, that there is something else.
Our engineering team made a decision in 2019 that works well enough for what we needed at the time. Whether it’s your preference or not, it’s not hurting anyone being there and it helps ensure the integrity of the artifact we release
It’s a valid question though! And I hope I was able to shed a little light on why the build number is there.
