GNU bug report logs - #62509
30.0.50; Changes to naming for Windows stapshots - PATCH

Previous Next

Package: emacs;

Reported by: Corwin Brust <corwin <at> bru.st>

Date: Tue, 28 Mar 2023 22:31:01 UTC

Severity: minor

Merged with 76638

Found in version 30.0.50

Full log


View this message in rfc822 format

From: Jim Porter <jporterbugs <at> gmail.com>
To: Corwin Brust <corwin <at> bru.st>, Stefan Kangas <stefankangas <at> gmail.com>
Cc: 62509 <at> debbugs.gnu.org
Subject: bug#62509: 30.0.50; Changes to naming for Windows stapshots - PATCH
Date: Tue, 12 Sep 2023 21:14:34 -0700
On 9/12/2023 7:33 PM, Corwin Brust wrote:
>  From my standpoint, it is challenging to pick the date to use.  I do
> most releases for GNU rather manually, and might take a day or two
> doing it. Is there information to be gained from knowing the "build
> start date" (but not time?) that isn't better sourced by git log
> <REVISION>?

I think so, yes. For those of us close to the development process, the 
Git SHA is the most-useful bit of info for sure, but thinking back to a 
couple of years ago before I contributed to Emacs, the date would have 
been a lot more useful. It would let me see at a glance how new the 
snapshot is. It would also make it easier to tell users what snapshot to 
try, e.g. if you're a package author: "Make sure you use the Emacs 
snapshot from at least YYYY-MM-DD in order to prevent such-and-such bug."

The timestamp of the file itself isn't as useful for this purpose since, 
as you say, the process is a bit manual and could be a few days after 
the latest commit.

As for what date exactly to use, I'd say, "Use the CommitDate in either 
US Eastern time (the FSF's time zone), or possibly UTC."




This bug report was last modified 100 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.