Hello,
While reviewing the Activity history, I noticed that an event timestamped at 1:20 PM was initially associated with Version 688399.
However, after additional scans or updates, it appears that the same 1:20 PM event is now shown under Version 589397.
I have attached before and after screenshots for your reference.
Could you please clarify why the version label changed?
Is this expected behavior, or could this indicate a potential issue in the versioning of activity events?
Thank you.
Hi,
It’s possible to edit the version string of analyses after they happen. I believe that’s what happened here.
HTH,
Ann
Hi,
Please note the sequence based on the attached screenshots:
- In the initial state (first screenshot), after raising Version 688399, the 1:20 PM and 1:19 PM events were correctly grouped under Version 688399.
- However, after further updates (second screenshot), the same 1:20 PM and 1:19 PM events are now grouped under Version 589397 instead.
In other words, events that were originally associated with Version 688399 have now shifted under the earlier Version 589397.
This was not manually changed from our side.
Could you please confirm whether this behavior — where events are automatically reassigned to a previous version — is expected?
Or does this indicate a possible issue in the version-to-activity mapping process?
Hi,
I’m well aware of the sequence.
What I’m saying is that someone with project admin permissions must have edited the version strings on the analyses in question.
Well, it wasn’t changed on our side.
There is nothing in SonarQube to edit an existing analysis. People have actually been asking for the ability to retroactively update analyses for years (to add data from long-running tests). The only thing that can happen to an analysis that’s already recorded is that “new” metric data is dropped when it moves from being the “Latest” analysis to an older one.
HTH,
Ann
Hi,
Understood on the limitation that existing analyses cannot be edited through SonarQube itself.
However, if no one with admin permissions on our side has made changes, and SonarQube does not provide a way to modify past analyses — then wouldn’t this unexpected change still indicate a potential bug?
We want to clarify whether there’s any scenario where version strings could be modified without manual action or known system behavior.
Hi,
There is not.
I would question your project admins more closely.
Ann
Hi,
I did a test myself.
Here’s the sequence I followed:
1234125344322123412After step 3, I noticed that the original analysis history for 123412 was no longer grouped under 123412, but instead appeared under 5344322.
Is this expected behavior?
If so, I’m wondering what the purpose of using version tag is — shouldn’t they separate analyses clearly instead of merging or reorganizing them under a different version?
Thank you.
Hi,
You’re expecting too much of this simple functionality. The analysis list presents a date/time-ordered list of analyses on file. Subsequent analyses with the same version string will be grouped together. That’s it.
HTH,
Ann
Hi,
I don’t believe I’m expecting too much here. From a user’s perspective, it is entirely reasonable to expect that analyses sharing the same version tag would remain grouped under that version in the history view.
That said, I’d like to ask: why is this behavior considered acceptable from a design standpoint, even though it creates confusion for users who rely on version tags to organize and interpret their analysis history?
If feedback on this kind of issue isn’t being considered, then what’s the purpose of exposing version tagging at all?
Hi,
I believe your expectations don’t align with the design which is, as I said, a simple date/time-ordered list.
HTH,
Ann
