Date of latest analysis in Overview Activity wrong

I also figured out, that on the Activity view on project Overall, the date of the latest analysis will be shown what is also wrong


Welcome to the community!

I’ve moved this post to a new thread because it’s unrelated to your first post.

What I believe you’re reporting here - that the latest analysis isn’t always reflected in the graph at the bottom of the project overview page - is something we also noticed internally recently. Here’s the ticket:

SONAR-13419 - Activity panel on overview doesn’t always show latest analysis


Hi Ann, thank you for the quick reply.

Yes and know. My reply to the original post was not written clear.
The issue is, that if I set the version e.g. 2020.610.0.10000 on a analysis e.g. May 15 2020, then in between are other analysis and the latest analysis was run on May 19 2020, then on the overview page the version 2020.610.0.10000 is visible with the May 19 2020, instead of May 15 2020

The version tag was sent originally on May 15 2020


Okay! So you really were just iterating on the main theme. Aaand now I’m sorry I split this out. At the same time, I’m reluctant to merge it back in because the whole thing will just get muddier.

Let me say that I didn’t respond to your initial post (and I guess the reason no one else did either) is that

  1. You correctly understand how it works today: if the new analysis has the same version stamp as the previous one, the version tag is ‘promoted’ to the newer analysis. What you’re seeing in the graph is just a side-effect of this; one you’ll see reflected throughout the SQ UI, wherever version is shown.
  2. You were asking for a new “feature”, i.e. that the behavior be changed, but I’m not in a position to say “yes”, “no”, or “maybe” to that. => Nothing to say

I would, however, like to give you a little background on the situation and push back a little.

First the pushback: if you send me 10 analyses in sequence with the same version stamp, which one “owns” that version? You say #1, and SonarQube says #10. Both are arguably arbitrary. I could just as easily say that all 10 should have the stamp. Or only #5.

Now the background: SonarQube’s origins are Maven-centric, and what you’re seeing here is that Maven-centrism at work. After I release version 2.6 (to pick a number at random) I start working on version 2.7. The first build after release is the current version of 2.7. Then I add some features and rebuild. Now the newer build is the current, ship-able iteration of 2.7. And that’s the mindset you’re seeing at work here.

Two things of note:

  1. You’re not the first person to give this type of feedback. I’ve referred your New Feature request for internal UX review. Aaand I wouldn’t hold my breath on this if I were you.
  2. You have the ability to pass a sonar.buildString property with each analysis. That might help you tell your analyses apart.


Thank you for the answer again :slight_smile:
If I take your example with the versioning, that means if I set the version string on a analysis, this should be the next version?
But at the time the development is ongoing on new features, I cannot know what is the next release version, because this is depending the versioning (SemVer or other versioning) and also on the work which needs to be done. Maybee the next release will be a bugfix release e.g. 2.1.0 -> 2.1.1, new features e.g. 2.1.0 -> 2.2.0 or breaking changes 2.1.0 -> 3.0.0 (in SemVer)

So your example may work for iterations, but not for a versioning like SemVer.


It means that if you had to release right now, that’s what would go out.

I don’t really see the contradiction here.

…from the release branch, not master, which so far is apparently versioned 2.2.0, right?

…from master

…and I guess this is one reason you have the ability to edit the version string within SonarQube.


Ok, I will try the sonar.buildString and check what I can do with this information.
Our main use case is, that we can see what changes were done on a branch since the latest release and not which changes were done for the next release.

But thank your for your feedback


Hi Christian,

For my own edification, would you might explaining the difference, please? Because I would have said they were the same thing.


Hi Ann

Yes both are the same thing - you are correct.
But on a master branch, we don’t know which release number will be the next one (this can be e.g. 2.5.0 or 3.0.0) and therefore our use case is to provide the version string with exactly the analysis run of the release build.

If we do it like you described above, we need to provide the next expected version, but if this version will be different we need to change this version manually on SonarQube -> There is an additional step which could forgotten by the person who creates the release…


Hi Christian,

Thanks for clarifying.

You’re right about this and internally we’ve forgotten it a few times.