windows Emacs-version issue

windows Emacs-version issue

[Sivaram Neelakantan]

m-x Emacs-version

GNU Emacs 28.1 (build 2, x86_64-w64-mingw32) of 2022-04-22
GNU Emacs 28.1 (build 2, x86_64-w64-mingw32) of 2022-04-20 #date is different

are the versions I'm seeing after downloading from dfferent GNU
mirrors[1].  What's the canonical official version to use please?

sivaram
--
1.  Lost my browser history, don't recollect which sites it was.

Re: windows Emacs-version issue

[Corwin Brust]

Hi Sivaram,

On Thu, May 5, 2022 at 9:26 AM Sivaram Neelakantan
<nsivaram.net@gmail.com> wrote:
>
> GNU Emacs 28.1 (build 2, x86_64-w64-mingw32) of 2022-04-22
> GNU Emacs 28.1 (build 2, x86_64-w64-mingw32) of 2022-04-20 #date is different

The newer (first above) is the current and correct version.

>
> are the versions I'm seeing after downloading from dfferent GNU
> mirrors[1].  What's the canonical official version to use please?
>

You would get different versions from different mirrors only in cases
where the mirroring is broken or delayed.  You can use this page to
check the status of any given mirror you happen to be using:

https://download.savannah.gnu.org/mirmon/allgnu/

The most recent official binaries for Emacs 28.1 for Windows are from
April 22nd.

There is also a set from April 30th which are identical to the April
22nd set except that Emacs' binaries contain debug symbols.  Each of
the downloads that include debug symbols includes DEBUG in name of the
downloadable file.

Re: windows Emacs-version issue

[Glenn Morris]

I think the point being made here is that binary releases, like source
releases, should be version tagged, and once uploaded, should not be
replaced in-situ (because that eg breaks checksumming, and is generally
confusing). IMO the binaries uploaded to ftp.gnu.org/gnu/emacs/windows
should have some extra version string added to the filename, and it
should be incremented if a new build is uploaded. Eg "emacs-28.1-version1.zip".

Ref https://lists.gnu.org/r/emacs-devel/2022-04/msg01108.html
for replacement of the original Windows files.

Re: windows Emacs-version issue

[Corwin Brust]

Hi Glenn, Thanks for the reply.

On Fri, May 6, 2022 at 3:48 PM Glenn Morris <rgm@gnu.org> wrote:
>
>
> I think the point being made here is that binary releases, like source
> releases, should be version tagged, and once uploaded, should not be
> replaced in-situ (because that eg breaks checksumming, and is generally
> confusing). IMO the binaries uploaded to ftp.gnu.org/gnu/emacs/windows
> should have some extra version string added to the filename, and it
> should be incremented if a new build is uploaded. Eg "emacs-28.1-version1.zip".
>
> Ref https://lists.gnu.org/r/emacs-devel/2022-04/msg01108.html
> for replacement of the original Windows files.

The Windows binaries are created from the same source archive as is
posted in the parent directory for the given Emacs version.  When I've
replaced the binary sett  it has been to resolve issues with the
build/packaging process.

That said, I'm open to discussing new/additional conventions for
naming that signify when the build occurred within the filenames if
people generally thing that is helpful -- personally, I'd tend to find
it confusing: I'd expect to find only one set of binaries for a given
version (notwithstanding the new set that includes debug symbols, of
course)..

Perhaps others will weigh in.

Re: windows Emacs-version issue

[Stefan Monnier]

> That said, I'm open to discussing new/additional conventions for
> naming that signify when the build occurred within the filenames if
> people generally thing that is helpful -- personally, I'd tend to find
> it confusing: I'd expect to find only one set of binaries for a given
> version (notwithstanding the new set that includes debug symbols, of
> course)..

I don't think there's much point in indicating the date when the build
occurred, but we should try to follow the principle that we never
*change* a file.  So when a new build is made to fix a problem, it
should be uploaded under a new name (the previous file can be removed).

How the new name is generated doesn't matter too much, so just try and
find something that won't bring up too many questions or confusion.
I've often seen "-N"  being used for that, so it could be
`emacs-28.1-2.zip` or `emacs-28.1-build2.zip`.


        Stefan

Re: windows Emacs-version issue

[Corwin Brust]

On Fri, May 6, 2022 at 4:24 PM Stefan Monnier <monnier@iro.umontreal.ca> wrote:
>
> How the new name is generated doesn't matter too much, so just try and
> find something that won't bring up too many questions or confusion.
> I've often seen "-N"  being used for that, so it could be
> `emacs-28.1-2.zip` or `emacs-28.1-build2.zip`.

I'd object to adding numbers without explanation to the end of the
file names but I could live with adding a -buildNN suffix.  TBH, I
really don't see the point.  Each version of a release file is
properly described as "the given version of Emacs without any build
issues we know of that aren't open in Debbugs".  But I understand that
view may be myopic.  I could live with this.

Eli,
Do you agree with the proposal to rename Window binary releases as described?

Re: windows Emacs-version issue

[Stefan Monnier]

Corwin Brust [2022-05-06 18:05:03] wrote:
> file names but I could live with adding a -buildNN suffix.  TBH, I
> really don't see the point.  Each version of a release file is
> properly described as "the given version of Emacs without any build
> issues we know of that aren't open in Debbugs".  But I understand that
> view may be myopic.  I could live with this.

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"?  ]


        Stefan

Re: windows Emacs-version issue

[Corwin Brust]

[-- Attachment #1: Type: text/plain, Size: 3181 bytes --]

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!

[-- Attachment #2: emacs-28.1-build.sh --]
[-- Type: text/x-sh, Size: 1435 bytes --]

#!/usr/bin/bash
# create Emacs 28.1 Windows binaries from the release tarball

rm -rf /d/emacs-build
mkdir /d/emacs-build
cd /d/emacs-build

tar -xf ~/emacs-upload/emacs-28.1.tar.xz
cd emacs-28.1/

# uncommenting these lines seems to enable ELN file generation
#make clean
#./autogen.sh

./configure --with-modules --without-dbus --with-native-compilation --without-compress-install CFLAGS=-O2

# bail if configure failed
RV=$?
if [[ "0" -ne "$RV" ]] ; then exit $RV ; fi

mkdir ../install/emacs-28.1
make install-strip -j 20 prefix=/d/emacs-build/install/emacs-28.1

# bail if make failed
RV=$?
if [[ "0" -ne "$RV" ]] ; then exit $RV ; fi

cp admin/nt/dist-build/emacs.nsi ../install/
cd ../install/
zip -r -9 emacs-28.1-no-deps.zip emacs-28.1/*
unzip -d emacs-28.1/bin ~/emacs-build/deps/emacs-28-deps.zip
zip -r -9 emacs-28.1.zip emacs-28.1/*

makensis -v4 -DEMACS_VERSION=28.1 -DVERSION_BRANCH=28.1 -DOUT_VERSION=28.1 emacs.nsi
# bail if we failed to create an installer
RV=$?
if [[ "0" -ne "$RV" ]] ; then exit $RV ; fi

# rest is signing and upload prep
mkdir upload
mv *.zip *.exe upload
cd upload

for f in * ; do gpg --batch --yes -b $f ; done

for f in *.{zip,exe} ; do cp /d/projects/emacs-build/new-hotness/emacs-28.directive $f.directive; perl -pi -e "s/__FILE__/$f/" $f.directive ; done

for f in emacs-28.1*{zip,exe} ; do gpg --batch --yes --clearsign $f.directive ; done

Re: windows Emacs-version issue

[Stefan Monnier]

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

There's no need to rename.  It's only something to remember for next
time such a situation comes up.

> Finally, this isn't a circumstance that's likely to repeat.

It's something that happens rarely but it does happen occasionally.
It can happen for binary packages like the one you distribute, or for
the release tarballs (we've had release tarballs with a minor error in
some documentation files where there is similarly a tendency to think
"bah I'll just replace the tarball with the new one"), ...

Just remember to avoid replacing a distribution file with a different
one, and prefer to use a new name for the new file instead.  It avoids
all kinds of (minor, but annoying) issues.

Which name you use at that occasion is not nearly as important as the
fact that it's a different name.  IIRC we've use `emacs-NN.MMa.tar.gz`
in the past.


        Stefan

Re: windows Emacs-version issue

[Eli Zaretskii]

> From: Corwin Brust <corwin@bru.st>
> Date: Fri, 6 May 2022 15:56:00 -0500
> Cc: Sivaram Neelakantan <nsivaram.net@gmail.com>,
>  Emacs developers <emacs-devel@gnu.org>
> 
> That said, I'm open to discussing new/additional conventions for
> naming that signify when the build occurred within the filenames if
> people generally thing that is helpful

My suggestion is to name them emacs-XX.YY-N.zip, where XX.YY is the
version and N is the ordinal number of the upload.  The first upload
could omit the "-N" part, or use N = 0.

This naming scheme is widely used on many sites, so people should be
familiar with it.