Re: windows Emacs-version issue

[Corwin Brust]

On Fri, May 6, 2022 at 6:15 PM Stefan Monnier <monnier@iro.umontreal.ca> wrote:
>
> For me the point is much simpler, in that it avoids issues like caches
> that are out of date [ And it simplifies questions about "did you
> download before or after I pushed the new build"?  ]
>

If issues are reported using M-x report-emacs then the build date is
provided, which can easily be contrasted with the date shown on the
FTP site.  Perhaps I'm missing something, but it's not clear to me yet
what practical problems might be resolved/reduced by adding (e.g.) a
build-count to the filename.  In this case, I believe if OP had been
aware of the sync-status page for the mirrors at the time of their
confusion, then it would have been clear that (my assumption here) the
discrepancy observed was due to a sync issue for the particular mirror
used.

I think it would be ideal to hear from other people who are using
these binaries releases before we elect a change in naming these
files; they have been consistent for quite some time. I was using them
for years before I volunteered to help create them.

In my view, the complexity of needing to understand whether one wants
the emacs-<version>.zip vs the emacs-<version>-installer.exe vs the
emacs-<version-no-deps.zip is already an hudle without expecting users
to also come to understand they should also select the highest
numbered build of the desired Emacs version (if several should happen
to be present).  Thus, I'm still feeling that further complicating the
naming of the files will create more confusion than it resolves. at
least WRT to release versions of Emacs.  By contrast, snapshot builds
do include the date-time of the build in the release filename since
several are cut from the same (main development) branch.  I assume
people who are after unreleased ("bleeding edge") Emacs binaries can
be expected to dig in a bit further to understand how to select the
download(s) they want to try out.

Finally, this isn't a circumstance that's likely to repeat.  For Emacs
28.1, the first release version I have prepared Windows binaries for,
I found the build process (uses scripts Phil had been maintaining)
worked perfectly for creating pre-releases and snapshots but, when the
time came, didn't work (or I fail to understand how to use them) to
create a release version from a source tar.  This resulted in four
"iterations" of me attempting to build manually from the Emacs 28.1
sources, ending in the now published binaries, which I suspect are the
final set for Emacs 28.1.  For the sake of posterity, I'm attaching
the script I used; I hope you will agree it's rather simple, as
compared to the scripts for creating dependency and dependency source
archives and release binariry sets for Windows (see
admin/nt/dist-build).

In any event, I consider it a rather atypical case that there will be
several binary distributions for Windows of a given release version of
Emacs, going forward.  In all cases, if a user's bug-report shows they
are using a build older than the publish date shown for the binaries
on the GNU FTP site, that user should be asked to install the
corrected build.

Thanks for your thoughts on this!

emacs-28.1-build.sh
Description: Text Data