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: Stability of core packages (was: Not easy at all to upgrade :core packages like Eglot) Date: Wed, 19 Apr 2023 14:55:30 +0300 Message-ID: <83fs8w84st.fsf@gnu.org> References: <87a5zj2vfo.fsf@gmail.com> <871qkom3fj.fsf@posteo.net> <83mt3b4yfc.fsf@gnu.org> <87edonlsxi.fsf@posteo.net> <83jzyf4vzb.fsf@gnu.org> <871qknllkj.fsf@posteo.net> <83fs934pjf.fsf@gnu.org> <87wn2fk47y.fsf@posteo.net> <83sfd2g2ek.fsf@gnu.org> <875y9yfxrr.fsf@gmail.com> <87y1muefks.fsf@gmail.com> <834jpifizy.fsf@gnu.org> <83y1mue1qi.fsf@gnu.org> <83sfd2e01f.fsf@gnu.org> <1a5e5837-513b-84d8-3260-cdbf42b71267@gutov.dev> <83sfcz9rf2.fsf@gnu.org> <09a49ab9-ac72-36a9-3e68-9c633710eba7@gutov.dev> <83r0sh8i1q.fsf@gnu.org> <35638c9d-e13f-fad8-5f95-ea03d65d4aa2@gmail.com> <83ildt808j.fsf@gnu.org> <93acbd4d-442f-b0a8-4476-44a76a1267d7@gmail.com> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="17387"; mail-complaints-to="usenet@ciao.gmane.io" Cc: dmitry@gutov.dev, joaotavora@gmail.com, emacs-devel@gnu.org To: Jim Porter Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Wed Apr 19 13:56:18 2023 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 1pp6Q5-0004Gs-CJ for ged-emacs-devel@m.gmane-mx.org; Wed, 19 Apr 2023 13:56:17 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1pp6PC-0006bs-QM; Wed, 19 Apr 2023 07:55:22 -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 1pp6PA-0006bM-Il for emacs-devel@gnu.org; Wed, 19 Apr 2023 07:55:20 -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 1pp6PA-0007Pn-3A; Wed, 19 Apr 2023 07:55:20 -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=K5KEkDMJK9GmoSxoc8T/S8QI8Grxshq9DG7g1S3OH/o=; b=X8paDOfsN5C4 C5d6zATbc/FTmY3JxI3E+rxqnll84O+HmMtQ0d+OL1Toep1chqAhs3KMHBmWwNV65sr/MjIxfB/LA dpyJQzgH5Fyr/BiJIR9jkvFuN9m3XHsCihR6FvELAoJ5SvZOcvrT3+tuWTq+9aANlhgmsggjM8iwd rZapSw+RLQmrbPIc0763Tv1tgdMS4kP8BHBXTypvLYABnsOWSTgu/azzrYeqTDSUX7Q6s8LOE5rQk cxt2XqCxCL0/HKRaK0a2gEbwKG7bCCTx4a2lmon48xVXEXICwIV5ac+TPMo32S1bSlTjAqq0+i437 voEbSfO8wrePgzMIK/3otQ==; Original-Received: from [87.69.77.57] (helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pp6P9-0002xA-9J; Wed, 19 Apr 2023 07:55:19 -0400 In-Reply-To: <93acbd4d-442f-b0a8-4476-44a76a1267d7@gmail.com> (message from Jim Porter on Tue, 18 Apr 2023 12:36:12 -0700) 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:305431 Archived-At: > Date: Tue, 18 Apr 2023 12:36:12 -0700 > Cc: dmitry@gutov.dev, joaotavora@gmail.com, emacs-devel@gnu.org > From: Jim Porter > > >> * Stable: the version of a package included in the latest Emacs tarball > >> * Latest: the latest version on GNU ELPA (etc) > >> * Devel: the latest version on GNU-devel ELPA (etc) > > > > I think we need only two. Stable can move to the next version, since > > packages are released more frequently than Emacs. > > At least from a user POV, I think it makes sense to distinguish among > all three of these. For example, I might use the version of Eglot in > Emacs 29, or I might install it from GNU ELPA, or I could even install > it from GNU-devel ELPA. I might even switch back and forth depending on > what my needs are (and in fact, that's exactly what I do with Eglot; > while I usually prefer to stick on the GNU ELPA version, sometimes I > switch to GNU-devel ELPA if there's a fix for a bug I find very bothersome). >From a user POV, what is the qualitative difference between "Latest" and "Stable"? As soon as some newer version on ELPA becomes stable enough, why should the user assign any significance to the previous version included in the last released Emacs tarball? Please keep in mind that the version you call "Stable" is just one that was ready in time for the last Emacs release, and is otherwise no different from what you call "Latest". IOW, assuming that versions in Emacs and on ELPA are declared "Stable" using the same criteria and the same procedures, they are not really different from the stability POV. Moreover, the version in Emacs could (hopefully, very infrequently) have some bug that went unnoticed during the pretest, and that bug could now be fixed in the ELPA version. Unless, that is, you somehow trust the decision-making process for an Emacs release much more than you trust the same process for ELPA releases. But in my book, those should be the same processes, especially if we ever get to the situation where such packages are not in emacs.git anymore. > I think this set of three levels also makes it easier - at least for me > - to reason about what to do with something like ElDoc. If a user > installs Eglot from GNU ELPA (i.e. the user gets "Eglot latest"), should > it automatically install ElDoc from GNU ELPA ("ElDoc latest") or should > it use the ElDoc from the Emacs tarball ("ElDoc stable")? My answer is NO, but that is a separate issue. > If there were only two levels - latest and devel - then I think the > answer to the Eglot/ElDoc problem would simply be: installing Eglot > latest should pull in ElDoc latest. By default, perhaps. But the user should still be able to say not to upgrade any dependencies unless they _must_ be upgrade, i.e. the package the user wants to upgrade _requires_ a newer version of another package. And again: this is a separate issue. > Since there's no higher "stability > gradation" than latest, we wouldn't really be able to say that > ElDoc-from-Emacs is better/stabler than ElDoc-from-ELPA. (Well, we can > still *say* that, but I think it helps to embed our reasoning for it > into these stability gradations.) It isn't our decision, it is up to the user. _We_ could recommend to upgrade to the latest version (if we will indeed get to the position where we can do that in good faith), but the user could decide he/she doesn't believe us, and doesn't want any additional risks. > > How is this different from what we have in Emacs? An exciting new > > feature is sometimes deferred to the next major release if the release > > branch is close enough to a release. There's nothing new here, just > > the fact that sometimes useful new features could destabilize Emacs, > > so one needs to choose which one it wants more. > > I think the main difference is that Eglot and Emacs (and ElDoc, for that > matter) all have different release cadences But this difference, if it is real, should really disappear, right? the periods of time when an Emacs release branch is closed to unsafe changes is nowadays relatively short, so there should be no problem for the core package to adhere to the same basic routine, i.e. keep the next "candidate for latest" closed to risky changes for a couple of months, before it actually becomes "latest". And then the difference will all but disappear. > With Emacs itself, we can ensure that every package that ships in > the tarball is works well with each other; when we distribute a > package on ELPA, this gets trickier. This "trickier" part will need to be fully resolved as part of getting our act together for the brave new world where core packages are maintained only on ELPA. So we might as well start now, because I see no reason why this difference should even exist -- it's not like we do in Emacs something too complicated and expensive. Btw, does package.el even allow to "downgrade" back to the version that came with Emacs?