Re: [External] : Re: Emacs 28.3 RC1 testing

[Corwin Brust <corwin@bru.st>]

On Sat, Mar 18, 2023 at 2:30 PM Drew Adams <drew.adams@oracle.com> wrote:
>
> > > > The latest RC I see at https://urldefense.com/v3/__https://alpha.gnu.org/gnu/emacs/pretest/windows/emacs-28
> > > > is RC1, dated 2023-02-19.

[snip]
>
> Duh.  For some reason I was seeing the "rc1" in the name
> and not noticing the "28.3" in the name.  Thx.

Yay, glad that was it. I appreciate that you are trying these out.

FTR, the prerelease tarball Stephen make creates Emacs 28.3.  That's
slightly different from what I think of as normal but might work to
our advantage.

The only part of the file names I thought about, particularly, was
deciding to append "-rc1" to the base names for this set. The base
names are generally derived from how Emacs built from the tarball
self-identifies. In particular, "nsi" script (which creates the
self-installer) is fairly fussy about how we name the folder
containing Emacs as produced by "make install"; I'd have had various
stuff to figure out I'd wanted to publish this as 28.2.90 (even
assuming I'm correct that would have been a more typical version
identifier for prerelease we're discussing, which I'm not quite ready
to).

Usually, the pre-release tarballs I've worked with create Emacs
versioned as X.Y.Z, with "X" being the relevant major version, "Y"
being the last stable minor version of that major version (or zero if,
e.g. the prerelease will become X.1), and "Z" being 90 + (count of
prior pre-release tarballs published).

In any case, even if I have *that* hopelessly (or quite trivally)
wrong, even aside how the Windows binaries are named, I think there
may be a practical upshot:

Stephen and I can potentially republish the same tarballs to the other
site to release Emacs 28.3, effectively turning the pre-release into
the release.

Do we agree that would work? And that we are ready? Are there
ancillary changes, such as updating online manuals[0]?

Eli?

[0] https://www.gnu.org/software/emacs/manual/