unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Corwin Brust <corwin@bru.st>
To: Stefan Monnier <monnier@iro.umontreal.ca>
Cc: Eli Zaretskii <eliz@gnu.org>, Glenn Morris <rgm@gnu.org>,
	 Sivaram Neelakantan <nsivaram.net@gmail.com>,
	Emacs developers <emacs-devel@gnu.org>
Subject: Re: windows Emacs-version issue
Date: Fri, 6 May 2022 20:42:57 -0500	[thread overview]
Message-ID: <CAJf-WoTHYJCLoAqhC6aKPV0UTrUDCJP7ycNwt5TRQrKV7xkfWw@mail.gmail.com> (raw)
In-Reply-To: <jwvh76245nf.fsf-monnier+emacs@gnu.org>

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

  reply	other threads:[~2022-05-07  1:42 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-05-05 14:26 windows Emacs-version issue Sivaram Neelakantan
2022-05-06 15:40 ` Corwin Brust
2022-05-06 20:48   ` Glenn Morris
2022-05-06 20:56     ` Corwin Brust
2022-05-06 21:24       ` Stefan Monnier
2022-05-06 23:05         ` Corwin Brust
2022-05-06 23:15           ` Stefan Monnier
2022-05-07  1:42             ` Corwin Brust [this message]
2022-05-07 13:18               ` Stefan Monnier
2022-05-07  5:43       ` Eli Zaretskii

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAJf-WoTHYJCLoAqhC6aKPV0UTrUDCJP7ycNwt5TRQrKV7xkfWw@mail.gmail.com \
    --to=corwin@bru.st \
    --cc=eliz@gnu.org \
    --cc=emacs-devel@gnu.org \
    --cc=monnier@iro.umontreal.ca \
    --cc=nsivaram.net@gmail.com \
    --cc=rgm@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).