[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Emacs 29.3 released

From: Michael Albinus
Subject: Re: Emacs 29.3 released
Date: Tue, 26 Mar 2024 15:28:26 +0100
User-agent: Gnus/5.13 (Gnus v5.13)

Eli Zaretskii <eliz@gnu.org> writes:

Hi Eli,

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

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 "". However, I see at least two problems:

- The Tramp version doesn't guarantee any longer uniqueness. Tramp 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, but in order to fix something for her there is also
  Tramp (let's say). I fear we'll have a hard time to explain,
  that is newer than

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

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.

(FWIW, I don't understand yet why 29.3 was such an emergency that it was
released w/o any warning in advance.)

> Thanks.

Best regards, Michael.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]