Re: Emacs 29.3 released

[Eli Zaretskii <eliz@gnu.org>]

> From: Michael Albinus <michael.albinus@gmx.de>
> Cc: emacs-devel@gnu.org
> Date: Tue, 26 Mar 2024 09:48:30 +0100
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> > How did that happen?  Which change to emacs-29 branch caused that, and
> >> > why was that change installed on the release branch?
> >>
> >> commit 115908469d30f8c40689673312f72b44c1631c6b
> >
> > Thanks, but why was the release branch synchronized with a pre-release
> > of Tramp?
> 
> Tramp 2.6 collects bug fixes. During pretest of Emacs 29.2, only serious
> bugs, which are a regression, were merged to the emacs-29 branch. After
> the Emacs 29.2 release, the current state of the tramp-2-6-stable branch
> (from the Tramp git repo) was merged to the emacs-29 branch, in order to
> have the other bug fixes there as well.
> 
> This is the usual procedure Tramp applies for years.

I see.  FWIW, I wasn't aware of this.  My mental model of the release
branch is that it is ready for an immediate release at all times.

Would it be possible to modify the Tramp revision on the release
branch so that it would not have the "-pre" suffix, and otherwise
leave intact the procedure by which you collect and merge fixes to the
release branch?  That would mean that if such an emergency release
does happen, you then advance the Tramp version to the next one (say,
from 2.6.3 to 2.6.4), and keep updating the release branch with any
further fixes.  If that is possible for you, I think it will be the
easiest solution for the future, if we ever need to make such
emergency releases again (something that I think is quite probable,
given that it happened both for Emacs 28 and Emacs 29).
Alternatively, we could record in make-tarball.txt the fact that such
releases must be coordinated with you.  From where I stand, this is
less desirable (as it adds a non-trivial prerequisite for such
releases, which could mean a delay if you are unavailable for some
reason), but still possible.

Thanks.