all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Troy Hinckley <comms@dabrev.com>
To: Drew Adams <drew.adams@oracle.com>, Eli Zaretskii <eliz@gnu.org>,
	 Stefan Kangas <stefankangas@gmail.com>,
	Corwin Brust <corwin@bru.st>
Cc: "Charalampos Mitrodimas" <charmitro@gmail.com>,
	"emacs-devel@gnu.org" <emacs-devel@gnu.org>,
	"Lars Ingebrigtsen" <larsi@gnus.org>
Subject: Re: [External] : Re: Emacs 28.3 RC1 testing
Date: Mon, 27 Mar 2023 10:12:35 -0600	[thread overview]
Message-ID: <604a027a-e74d-4f61-938e-9eaf521ee016@Spark> (raw)
In-Reply-To: <CAJf-WoSQEBgdwT0FJyG9ct3k43BV_OQ6ir+WU53H5+YGq4Ccng@mail.gmail.com>

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

Who needs to sign off to do the release? Is that only Eli or Stefan?
On Mar 18, 2023 at 3:08 PM -0600, Corwin Brust <corwin@bru.st>, wrote:
> 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/

[-- Attachment #2: Type: text/html, Size: 2987 bytes --]

  reply	other threads:[~2023-03-27 16:12 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <06c78bbd-0e25-4bd3-bb58-d13e1c5003ac@Spark>
2023-03-17 22:52 ` Emacs 28.3 RC1 testing Troy Hinckley
2023-03-18 10:23   ` Charalampos Mitrodimas
2023-03-18 15:51     ` Corwin Brust
2023-03-18 16:27       ` [External] : " Drew Adams
2023-03-18 16:49         ` Charalampos Mitrodimas
2023-03-18 16:55           ` Drew Adams
2023-03-18 16:58           ` Corwin Brust
2023-03-18 19:30             ` Drew Adams
2023-03-18 21:08               ` Corwin Brust
2023-03-27 16:12                 ` Troy Hinckley [this message]
2023-03-27 16:35                   ` Eli Zaretskii
2023-04-04 12:46                     ` Troy Hinckley

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

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

  git send-email \
    --in-reply-to=604a027a-e74d-4f61-938e-9eaf521ee016@Spark \
    --to=comms@dabrev.com \
    --cc=charmitro@gmail.com \
    --cc=corwin@bru.st \
    --cc=drew.adams@oracle.com \
    --cc=eliz@gnu.org \
    --cc=emacs-devel@gnu.org \
    --cc=larsi@gnus.org \
    --cc=stefankangas@gmail.com \
    /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 external index

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

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.