From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: Emacs 29.3 released Date: Tue, 26 Mar 2024 21:35:53 +0200 Message-ID: <86o7b0iy5i.fsf@gnu.org> References: <86edbzyavw.fsf@gnu.org> <87r0fzsbxz.fsf@gmx.de> <86wmprjumv.fsf@gnu.org> <875xxbtmpp.fsf@gmx.de> <86r0fzjs9x.fsf@gnu.org> <87il199y5d.fsf@gmx.de> <865xx9jh3y.fsf@gnu.org> <875xx9f4ol.fsf@gmx.de> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="20916"; mail-complaints-to="usenet@ciao.gmane.io" Cc: emacs-devel@gnu.org To: Michael Albinus Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Tue Mar 26 20:36:52 2024 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1rpCbM-0005HN-LX for ged-emacs-devel@m.gmane-mx.org; Tue, 26 Mar 2024 20:36:52 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1rpCaU-0003he-Sf; Tue, 26 Mar 2024 15:35:58 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1rpCaT-0003hU-7F for emacs-devel@gnu.org; Tue, 26 Mar 2024 15:35:57 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1rpCaS-00065R-Tn; Tue, 26 Mar 2024 15:35:56 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=AqBcPkz5lCvHvz508Mle+IZjN9rpIVzhKpD6CdralLs=; b=QJFpx26lm8IW 9ZDXBtEOVBWK4kjGg6wSpVqcJ+uMihDvlVIBPuPxuBSo3ZFCKwmRJ7AQmyos2jEI8vC+LBgnO1o5i NN83BU+jvjf1GNhqcnpkdkMPLCEeMo0YHWmWdDu1qWnEfnycn2Vn9zVXK9psakrpVPO9Fqbu/1ohU tHyE/dj5ne9RBNeXdw4iaNWvh0cFnnBo1eOxqvGH7Ac/aMaYkMxFZSHD6ScxdA5Y102zFaCqNuObg GoDSqmWL6R67Bc3t0MlHMx9b5iU8Jf1PdT3oUS0pGzLcCM7d10WsPuKhzoLz24DRVXKKb+DlyLu9U GzF3t2kU23gnJEEzkEY3tg==; In-Reply-To: <875xx9f4ol.fsf@gmx.de> (message from Michael Albinus on Tue, 26 Mar 2024 15:28:26 +0100) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.devel:317315 Archived-At: > From: Michael Albinus > Cc: emacs-devel@gnu.org > Date: Tue, 26 Mar 2024 15:28:26 +0100 > > > 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 "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? > > 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. 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. > (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.