Re: Emacs 29.3 released

[Eli Zaretskii]

> From: Michael Albinus <michael.albinus@gmx.de>
> Cc: emacs-devel@gnu.org
> Date: Wed, 27 Mar 2024 09:27:40 +0100
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> It would be possible. I could change the Tramp version in the release
> >> branch to the next anticipated release number. So I could change it now
> >> to "2.6.3.29.4". However, I see at least two problems:
> >>
> >> - The Tramp version doesn't guarantee any longer uniqueness. Tramp
> >>   2.6.3.29.4 would differ today and tomorrow. That was the reason to use
> >>   such an ambiguous version like 2.6.3-pre.
> >>
> >> - We might run into problems on ELPA. A user sees a builtin version of
> >>   Tramp 2.6.3.29.4, but in order to fix something for her there is also
> >>   Tramp 2.6.2.9 (let's say). I fear we'll have a hard time to explain,
> >>   that 2.6.2.9 is newer than 2.6.3.29.4.
> >
> > Then perhaps make-tarball.txt needs to say that the version of Tramp
> > should be changed from X.Y.Z-pre to X.Y.Z as part of preparing the
> > release?  Or even do this automatically in admin/admin.el, as part of
> > set-version?
> 
> No. Release X.Y.Z would attribute the full release of Tramp, not only
> the part which is integrated into Emacs.

So what is it that you do with Tramp to make its parts in Emacs ready
for a release?  If I'd alerted you to the imminent release, what would
you have done before telling me that Tramp is ready?

> >> Perhaps it must not be coordinated with "me" only. A single
> >> announcement, that there will be an emergency release within two days
> >> would have helped. Usually, I scan Emacs related messages every single day.
> >>
> >> If I am unavailable that time, so be it. Not worse than now.
> >
> > Preparation of a release tarball is a precarious job: since we don't
> > lock the Git repository while the release is being worked on, it must
> > be done very quickly; any commits someone does during the time it
> > takes to do all the steps necessary for producing the tarball is a
> > setback that requires to go back several steps and start anew.  So any
> > additional dependency is a disadvantage I'd like to avoid.
> 
> You could start the prepare the release tarball after the grace period.

Theoretically, maybe.

> >> (FWIW, I don't understand yet why 29.3 was such an emergency that it was
> >> released w/o any warning in advance.)
> >
> > Because it makes no sense to announce in advance that Emacs has
> > security vulnerabilities.  It's akin to waving the proverbial red flag
> > at a bull.
> 
> I haven't proposed that such an announcement shall happen. I have only
> proposed to send an alert like "Heads up! The next Emacs release will
> happen on Sunday!".

Without any explanation, that wouldn't be accepted by the community as
we know it.  There would be a flood of questions, and what could I
possibly say in response? "I can tell you, but then I'll have to have
you taken out and shot"?

> Btw, I've got already the first rant that "Tramp 2.6.3-pre" is useless
> for determining, whether a given patch is contained in Emacs 29.3. Right
> they are!
> 
> <https://github.com/magit/magit/issues/3624#issuecomment-2022167445>

If you think this is bad enough, we can always release Emacs 29.4.