About LibreOffice information, add the date-time of the build after the build ID, I think a useful information, to see at a glance. Version: 24.2.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: be9d7bee88eff89c0d361f23abb447ac2086c3b4 CPU threads: 16; OS: Windows 10.0 Build 22621; UI render: Skia/Vulkan; VCL: win Locale: es-ES (es_ES); UI: en-US Calc: CL threaded Jumbo Build ID: be9d7bee88eff89c0d361f23abb447ac2086c3b4 YYYYMMDDHHMM BTW, Locale and Calc information, could be in the same line avoiding one line in the information.
(In reply to m.a.riosv from comment #0) > I think a useful information, to see at a glance. What does it give to a reader? The date of a build is very likely to be misleading. One build of 7.6.1.2 (say, in DistroA) will definitely have a different YMD compared to a build of 7.6.1.2 in DistroB.
(In reply to Mike Kaganski from comment #1) >................ > What does it give to a reader? The date of a build is very likely to be > misleading. One build of 7.6.1.2 (say, in DistroA) will definitely have a > different YMD compared to a build of 7.6.1.2 in DistroB. So we can't have the date corresponding to the build ID? And e.g., when we are looking at recent master builds, we can quickly know if it is from yesterday or a week ago. Can it bother?
(In reply to m.a.riosv from comment #2) > So we can't have the date corresponding to the build ID? Ah, so likely you want a timestamp from the *commit* (that hash is used as the build id), right? And likely, the timestamp of its merge. I'd say, it makes sense, but only for debug builds.
Thanks m.a.riosv. In a way, "Build ID" is misleading. Maybe a better name would be "Last commit"? I kind of agree with Mike, would be most useful for debug and daily builds, where we have dozens of builds for a single version number. YYYY-MM-DD is probably sufficient. I would be happy to have that information at a glance when doing QA work on Bugzilla, but given that the information is one hyperlink away, I think the priority is "low".
*** Bug 166703 has been marked as a duplicate of this bug. ***
So, is the current ask here for the commit timestamp, or the build timestamp? If it's the former, let's edit the title; if it's the latter, my bug is not a dupe.
*** Bug 79438 has been marked as a duplicate of this bug. ***
*** Bug 167151 has been marked as a duplicate of this bug. ***
*** Bug 87021 has been marked as a duplicate of this bug. ***
The git log link from the Help -> About has been broken (bug 166774 and the Redmine 3836 issue). Including the date of the git head build in the dialog would be helpful without having to dig out build info.
Miguel, can you answer my question from comment #6?
(In reply to Eyal Rozenberg from comment #11) > Miguel, can you answer my question from comment #6? Title adjusted. As clarified comment 3 and comment 4, the date to list is the build date corresponding to the git head of the branch being built. The Help dialog identifies the branch, the SHA1 hash supplemented by at least YYYY-MM-DD or maybe with HH:MM would suffice. Still, need to get the REDMINE issue 3836 corrected and make the git log (listing the commits up to the last commit) reliably available via browser URL.
Since opening the commit log is no longer possible this is no longer just a nice-to-have enhancement as currently it is hard to know how old a certain main build is. Setting importance to medium.