I'd like to add my vote to this issue, but the option seems disabled - is it because this issue is marked "Resolved"?
I'm not a contributor, and realize that there are often thorny details the user doesn't see, but it seems like there might be a big difference between solving the general form of the problem and just implementing a minimal use case (no cross-referencing, no renames, etc.) that achieves the main goal of visualizing old builds. I'm not sure it's really a new visualization combining all the history that's desirable. A user (I think) just wants to be able to see the same visualization they saw the day before, somewhere in the UI, even if it can't include the newer builds.
In my mind, it's not even a prerequisite for all the sequences of builds to be on the same screen as long as you can find them somewhere. For instance, based on the mockup screen example, what if:
- If the user clicks on the project page "TestProject" it shows the same Stage View it would show today, with the recent builds #4, #5, #6 that have the same stages.
- If the user clicks the build page for #3, it would have a new link "Stage View History", which would open a display showing what the Stage View used to look like - build #3 with the old stages
- If the user clicks the build page for #1, it also would have "Stage View History", which would show the even-earlier Stage View - build #1 with just the two stages.
- Or to make it a better example, if there were a build #2 with the same stages as #3, the Stage View History for build #3 would show two builds #2 and #3, so that even though these two builds weren't with the current stages, you could see them shown together because they had the same stages.
Don't the build logs have all the information the UI would need to do that? Wouldn't the current algorithm suffice, just pretending the older build is the latest build that it must count the stages from?