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

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

[Corwin Brust]

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

Today I put an initial set of Emacs 30 "snapshot" binaries for Windows
on GNU alpha.  In the process, I created a new folder for emacs-30[0].
At the moment, this folder is without the customary README.

I've attached a patch that suggests changes based on how I name the
snapshots, locally, when building them.  All of this is totally open
to discussion :)

Previously snapshot builds included a (rather nebulous) date, e.g.:
  emacs-30-YYYY-MM-DD-no-deps.zip.

Locally, my snapshots, instead of any date, include the git revision
short-code effective in the source tree where the build is taking
place, e.g.:
  emacs-30-28a9438169f-no-deps.zip

TIA for sharing your thoughts; I can easily rename files, including
those already posted if necessary.

Background:

The file admin/nt/dist-build/README-windows-binaries is usually placed
at the root of each new folder that will contain windows binaries, for
example the "emacs-30" folder for snapshot (and eventually pre-release)
builds from (as currently called) "master".

The attached patch updates this file to reflect a change in how I've
been naming snapshot binaries, locally.

Snapshot binaries are in-tree source builds, rather than being made
from a release --or prerelease-- tarball.

[0] https://alpha.gnu.org/gnu/emacs/pretest/windows/emacs-30

In GNU Emacs 30.0.50 (build 1, x86_64-w64-mingw32) of 2023-03-27 built
 on AVALON
Repository revision: 0bd2bbc0c2cb06cd254bf67f75d284f4c16f45a8
Repository branch: master
Windowing system distributor 'Microsoft Corp.', version 10.0.19043
System Description: Microsoft Windows 10 Home (v10.0.2009.19043.2364)

Configured using:
 'configure --with-modules --without-dbus --with-native-compilation
 --without-compress-install --with-tree-sitter CFLAGS=-O2'

Configured features:
ACL GIF GMP GNUTLS HARFBUZZ JPEG JSON LCMS2 LIBXML2 MODULES NATIVE_COMP
NOTIFY W32NOTIFY PDUMPER PNG RSVG SOUND SQLITE3 THREADS TIFF
TOOLKIT_SCROLL_BARS TREE_SITTER WEBP XPM ZLIB

Important settings:
  value of $LANG: ENU
  locale-coding-system: cp1252

Major mode: Lisp Interaction

Minor modes in effect:
  tooltip-mode: t
  global-eldoc-mode: t
  eldoc-mode: t
  show-paren-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  tool-bar-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  line-number-mode: t
  indent-tabs-mode: t
  transient-mark-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t

Load-path shadows:
None found.

Features:
(shadow sort mail-extr emacsbug message mailcap yank-media puny dired
dired-loaddefs rfc822 mml mml-sec password-cache epa derived epg rfc6068
epg-config gnus-util text-property-search time-date mm-decode mm-bodies
mm-encode mail-parse rfc2231 mailabbrev gmm-utils mailheader cl-loaddefs
comp comp-cstr warnings icons subr-x rx cl-seq cl-macs gv cl-extra
help-mode bytecomp byte-compile cl-lib sendmail rfc2047 rfc2045
ietf-drums mm-util mail-prsvr mail-utils rmc iso-transl tooltip cconv
eldoc paren electric uniquify ediff-hook vc-hooks lisp-float-type
elisp-mode mwheel dos-w32 ls-lisp disp-table term/w32-win w32-win
w32-vars term/common-win tool-bar dnd fontset image regexp-opt fringe
tabulated-list replace newcomment text-mode lisp-mode prog-mode register
page tab-bar menu-bar rfn-eshadow isearch easymenu timer select
scroll-bar mouse jit-lock font-lock syntax font-core term/tty-colors
frame minibuffer nadvice seq simple cl-generic indonesian philippine
cham georgian utf-8-lang misc-lang vietnamese tibetan thai tai-viet lao
korean japanese eucjp-ms cp51932 hebrew greek romanian slovak czech
european ethiopic indian cyrillic chinese composite emoji-zwj charscript
charprop case-table epa-hook jka-cmpr-hook help abbrev obarray oclosure
cl-preloaded button loaddefs theme-loaddefs faces cus-face macroexp
files window text-properties overlay sha1 md5 base64 format env
code-pages mule custom widget keymap hashtable-print-readable backquote
threads w32notify w32 lcms2 multi-tty make-network-process
native-compile emacs)

Memory information:
((conses 16 80396 28348)
 (symbols 48 7205 0)
 (strings 32 21339 1787)
 (string-bytes 1 629300)
 (vectors 16 16571)
 (vector-slots 8 333592 20388)
 (floats 8 30 52)
 (intervals 56 245 0)
 (buffers 984 10))

[-- Attachment #2: 0001-update-FTP-download-instructions-for-Windows.patch --]
[-- Type: application/octet-stream, Size: 2564 bytes --]

From ad7b1298fc240273b5d35c990d8d757fd83c497b Mon Sep 17 00:00:00 2001
From: Corwin Brust <corwin@bru.st>
Date: Tue, 28 Mar 2023 14:10:44 -0500
Subject: [PATCH] ; update FTP download instructions for Windows

* admin/nt/dist-build/README-windows-binaries: snapshots are now
versioned with Emacs major version (e.g. 30) and the revision short
id (and no longer include a date).
---
 admin/nt/dist-build/README-windows-binaries | 21 +++++++++++++++------
 1 file changed, 15 insertions(+), 6 deletions(-)

diff --git a/admin/nt/dist-build/README-windows-binaries b/admin/nt/dist-build/README-windows-binaries
index f53558960c4..6c348034122 100644
--- a/admin/nt/dist-build/README-windows-binaries
+++ b/admin/nt/dist-build/README-windows-binaries
@@ -4,7 +4,7 @@ See the end of the file for license conditions.
 		      Precompiled Distributions of
 			   Emacs for Windows
 
-                           Jan 14, 2021
+                           March 28, 2023
 
   This directory contains precompiled distributions for GNU Emacs on
   Windows
@@ -42,7 +42,7 @@ emacs-$VERSION-no-deps.zip
 
 Contains Emacs without any dependencies. This may be useful if you
 wish to install where the dependencies are already available, or if
-you want the small possible Emacs.
+you want the smallest possible Emacs.
 
 In addition, we provide the following files which will not be useful
 for most end-users.
@@ -70,10 +70,19 @@ development cycle, for those interested in following this cycle.  They
 are not recommended for normal users; however, they are useful for
 people who want to report bugs against the current master.
 
-The files follow the same naming convention, but also include a date
-(and sometimes information about their branch).  The Emacs source at
-the time of these builds is also distributed.
+The Emacs source at the time of these builds is also distributed,
+typically as emacs-$VERSION-src.zip.
 
+$VERSION
+========
+
+In the case of release (and pre-release) versions of Emacs, $VERSION
+is simply the version of Emacs provided/supported by the binary
+release package.
+
+For snapshots, $VERSION is:
+
+  ${EMACS_MAJOR_VERSION}-${BRANCH_REV_SHORT_ID}
 
 LICENSE
 ======
@@ -91,4 +100,4 @@ MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
 GNU General Public License for more details.
 
 You should have received a copy of the GNU General Public License
-along with GNU Emacs.  If not, see https://www.gnu.org/licenses/.
+along with GNU Emacs.  If not, see https://www.gnu.org/licenses/.
\ No newline at end of file
-- 
2.40.0.windows.1

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

[Stefan Kangas]

Corwin Brust <corwin@bru.st> writes:

> Today I put an initial set of Emacs 30 "snapshot" binaries for Windows
> on GNU alpha.  In the process, I created a new folder for emacs-30[0].
> At the moment, this folder is without the customary README.
>
> I've attached a patch that suggests changes based on how I name the
> snapshots, locally, when building them.  All of this is totally open
> to discussion :)
>
> Previously snapshot builds included a (rather nebulous) date, e.g.:
>   emacs-30-YYYY-MM-DD-no-deps.zip.
>
> Locally, my snapshots, instead of any date, include the git revision
> short-code effective in the source tree where the build is taking
> place, e.g.:
>   emacs-30-28a9438169f-no-deps.zip
>
> TIA for sharing your thoughts; I can easily rename files, including
> those already posted if necessary.

How about

    emacs-30-YYYY-MM-DD-REVISION-no-deps.zip.

> Background:
>
> The file admin/nt/dist-build/README-windows-binaries is usually placed
> at the root of each new folder that will contain windows binaries, for
> example the "emacs-30" folder for snapshot (and eventually pre-release)
> builds from (as currently called) "master".
>
> The attached patch updates this file to reflect a change in how I've
> been naming snapshot binaries, locally.
>
> Snapshot binaries are in-tree source builds, rather than being made
> from a release --or prerelease-- tarball.
>
> [0] https://alpha.gnu.org/gnu/emacs/pretest/windows/emacs-30

Please skip this chunk, though:

@@ -91,4 +100,4 @@ MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
 GNU General Public License for more details.

 You should have received a copy of the GNU General Public License
-along with GNU Emacs.  If not, see https://www.gnu.org/licenses/.
+along with GNU Emacs.  If not, see https://www.gnu.org/licenses/.
\ No newline at end of file

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

[Corwin Brust]

On Fri, Sep 1, 2023 at 2:39 PM Stefan Kangas <stefankangas@gmail.com> wrote:
>
> Corwin Brust <corwin@bru.st> writes:
>
> >
> > Locally, my snapshots, instead of any date, include the git revision
> > short-code effective in the source tree where the build is taking
> > place, e.g.:
> >   emacs-30-28a9438169f-no-deps.zip
> >
> > TIA for sharing your thoughts; I can easily rename files, including
> > those already posted if necessary.
>
> How about
>
>     emacs-30-YYYY-MM-DD-REVISION-no-deps.zip.

I'd prefer not; however, it seems possible you can see use from the
date there which I cannot.

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

Moveover, considering viewing a given version subfolder over HTTP,
sorting by the date column must surely give the same order as name
after adding this, reducing the utility of sorting by name that
otherwise helps quickly find binaries corresponding to a given
revision.

In any case, although I don't prefer it, it is not a problem to resume
including a common date in the file names constituting a release given
I know what date to use.

>
> @@ -91,4 +100,4 @@ MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
>  GNU General Public License for more details.
>
>  You should have received a copy of the GNU General Public License
> -along with GNU Emacs.  If not, see https://www.gnu.org/licenses/.
> +along with GNU Emacs.  If not, see https://www.gnu.org/licenses/.
> \ No newline at end of file
>

Yes, thanks; I see to that in a next version once we've confirmed on
how to name the files :blush:

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

[Jim Porter]

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

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

[Stefan Kangas]

Jim Porter <jporterbugs@gmail.com> writes:

> 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'd probably prefer UTC, as it's less US-centric, but I don't think it's
super important.  As you say, it's more to give a rough indicator of the
age of a tarball, and the SHA is there too if anyone wants the details.

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?

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

[Corwin Brust]

On Wed, Sep 13, 2023 at 7:12 AM Stefan Kangas <stefankangas@gmail.com> wrote:
>
> Jim Porter <jporterbugs@gmail.com> writes:
>
> > 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'd probably prefer UTC, as it's less US-centric, but I don't think it's
> super important.  As you say, it's more to give a rough indicator of the
> age of a tarball, and the SHA is there too if anyone wants the details.
>

I prefer UTC also.

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

[Stefan Kangas]

Corwin Brust <corwin@bru.st> writes:

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

Sounds good.

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

[Jim Porter]

On 9/13/2023 6:06 AM, Corwin Brust wrote:
> 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.

Well, I think this would mainly be useful for the more-enthusiastic 
users who want to try out new things or are impatiently waiting for some 
bugfix only on the dev version. I'm not sure whether the actual Emacs 
maintainers would direct users to the snapshots, but third-party package 
authors might.

> 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)?

Including the time is fine too. I'm not sure how much value there is in 
that (personally, I'd only ever use the date for an approximate value of 
"how new is this"), but it doesn't cause any harm.