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".