bug#62509: 30.0.50; Changes to naming for Windows stapshots - PATCH

[Corwin Brust]

On Tue, Sep 12, 2023 at 11:14 PM Jim Porter <jporterbugs@gmail.com> wrote:
>
> 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.

That's helpful.  I was under the impression we published snapshots for
developers and didn't typically direct users to use them at all
(except for pre-release snaps and special circumstances such as
recently when glibc got several potentially breaking changes.

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

I'm still puzzled as to why we should exclude the time component.
Wouldn't that be rather more useful than including the date alone for
those looking to see what revision is that last included (but doing so
without referencing git logs)?

As to collecting the date, my approach would be to take the date at
the end of the process by extracting the date of REVISION from git
log.  Any concerns with this approach?