From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Dmitry Gutov 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 22:25:08 +0300 Message-ID: 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> <83a5z482e3.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="5766"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.10.0 Cc: joaotavora@gmail.com, emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Wed Apr 19 21:26:04 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 1ppDRL-0001D0-4d for ged-emacs-devel@m.gmane-mx.org; Wed, 19 Apr 2023 21:26:04 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ppDQf-0006Rc-JY; Wed, 19 Apr 2023 15:25:21 -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 1ppDQa-0006RO-K8 for emacs-devel@gnu.org; Wed, 19 Apr 2023 15:25:16 -0400 Original-Received: from new2-smtp.messagingengine.com ([66.111.4.224]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ppDQY-00006e-6R; Wed, 19 Apr 2023 15:25:16 -0400 Original-Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailnew.nyi.internal (Postfix) with ESMTP id C2CDF5823B9; Wed, 19 Apr 2023 15:25:12 -0400 (EDT) Original-Received: from mailfrontend2 ([10.202.2.163]) by compute5.internal (MEProxy); Wed, 19 Apr 2023 15:25:12 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gutov.dev; h=cc :cc:content-transfer-encoding:content-type:content-type:date :date:from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:sender:subject:subject:to:to; s=fm2; t= 1681932312; x=1681935912; bh=hqKxPhSJLhcvHAbKGjgcX1dKuEInhltiC9t RMKtBE7A=; b=LcLXo+0EDTDRNHSTdhFQUnk0Stw6qDyDVm4gOmOMulnAtvMDfQt TJD/Wrx18qZ+IMkzATmj8bdya/WyHeVjglfmStgtlz3tgmkJDRLdD+FxBkyI+cRu VK4EJ1fkw/rSTZKvUpsq3H5xLAto/TRKgYottbvDZUzf6Q0I1Se+Palzv6eyb+Za hCbfUCUfqatJdCbyEzTJapTcL3B/bVL7B97Hv0GHvjfa7BKpwjhMnQNPiXuWzWCj 6fgdjWfHvUfCSh9/HCNUaGtLUiZJ8/unsrvkyXfYTp7wcFgIyOz32XBoRrJDE2RL lpTb6/DT2Ra8eXO8P/Lau2SuyxDlt84Of6Q== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:content-type:date:date:feedback-id:feedback-id :from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:sender:subject:subject:to:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; t= 1681932312; x=1681935912; bh=hqKxPhSJLhcvHAbKGjgcX1dKuEInhltiC9t RMKtBE7A=; b=V2ztxYijN6kfzCkFhk3hOqtR7oO7ono5a+GRsVs7kxqIk0x/fap daDtoBJEdfannitK0DrC+chjXGtM3H5YbhGgqHb1gxSOq4aeyLMQ0X0iDhfsrfIm eROkFFGmZmF4nHiHzITiPxDG6KQG3hjIyBSamycrJlnu8OEI9VsoLqVFzpofPdHC pxlLYuVdq5KWFqS5M3+Qxi+neW9eZ2asXArR++8jWSa3JIp9NF2V9XA017dUzuKo RaXoQJw0EkPC+WszL8BwHLpM/cPAacQr/NeDl+ECwUO0/25F9hdI6tsdUL/4340n mknQ7sVK3IhWtj3lAgwcVnPGUh87X5aihLw== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvhedrfedttddgudeflecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmd enucfjughrpefkffggfgfuvfevfhfhjggtgfesthekredttdefjeenucfhrhhomhepffhm ihhtrhihucfiuhhtohhvuceoughmihhtrhihsehguhhtohhvrdguvghvqeenucggtffrrg htthgvrhhnpefhffehleejffegffeugefhkeektdffgfehjedvgeejtedtudehueffgffg feejheenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpe gumhhithhrhiesghhuthhovhdruggvvh X-ME-Proxy: Feedback-ID: i0e71465a:Fastmail Original-Received: by mail.messagingengine.com (Postfix) with ESMTPA; Wed, 19 Apr 2023 15:25:11 -0400 (EDT) Content-Language: en-US In-Reply-To: <83a5z482e3.fsf@gnu.org> Received-SPF: pass client-ip=66.111.4.224; envelope-from=dmitry@gutov.dev; helo=new2-smtp.messagingengine.com X-Spam_score_int: -53 X-Spam_score: -5.4 X-Spam_bar: ----- X-Spam_report: (-5.4 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-2.597, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=ham autolearn_force=no X-Spam_action: no action 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:305457 Archived-At: On 19/04/2023 15:47, Eli Zaretskii wrote: >>> This will be one of the serious issues if we ever move to having some >>> packages only in elpa.git, and will then bundle them when preparing an >>> Emacs release tarball. It will be imperative to know at that time >>> which version/branch of each such package to take as part of preparing >>> a release. We must have a solution by then, so this is as good time >>> as any to start discussing the issue. >> >> Sure. Please keep in mind, however, that very few of external packages >> have separate branches for releases and development. I guess Org does, >> but I'm not sure if others exist. One of the reasons for that is that >> the ELPA repositories only package the very latest released version >> anyway and quickly delete the older ones. And package.el is the foremost >> distribution method for Elisp code. > > Then maybe ELPA will have to change as well. I don't think that should be, or can be reasonably required. But that can be put it to a separate discussion. With Stefan and Philip involved, probably. >> So every time a new version if tagged, it's a value judgment on the part >> of the maintainer: whether enough time has passed since the most recent >> big feature was added, whether there were bug reports or not. > > Similar judgment calls are necessary for Emacs. So I see nothing here > that brings some fundamentally new issues. > > Moreover, I don't see how this affects the need to have good criteria > for stability, and the importance of applying those criteria when > deciding which versions to bundle with Emacs. Ok, if the question is just "how to choose the version of :core package to bundle with an Emacs release", then just see the criterion "N weeks have passed without issue" that I just described in the bug thread. This one doesn't need any changes to ELPA, and I've been using it, more or less, for some years now. >>> If some core package is not tested enough before it gets a new >>> version, then why are we okay with telling users of a stable Emacs to >>> update the package willy-nilly as soon as another version is on ELPA? >>> Shouldn't we at least warn them, or, better, somehow indicate that >>> this version is not yet considered stable? >> >> I have a different answer from all that had been presented here: because >> the user can uninstall it. > > User can also downgrade to a previous version of the package, don't > they? Or if they cannot, they should be able to do that. Even if there was such possibility, they wouldn't have a single stable version to go back to (they'd have to make a choice). When we bundle a version, that's one fewer question to answer. > Once that > is possible, what exactly is the difference between these two kinds of > packages? Downgrading to an older version when a newer one is buggy > or otherwise unsatisfactory should be supported for all packages. Then the difference would be that we hand-picked a set of particular versions of packages, whereas for third-party packages that was done (or failed to be done) by other people we have no responsibility over. > Also, does package.el support "downgrading" to the bundled version? > Did anyone actually try that? In particular, what happens with the > dependencies the user upgraded together with the package being > "uninstalled", due to the minimum requirements of that package? It should work by "uninstalling" the package. An when you uninstall a package, package.el warns you about any dependencies that would be broken this way. Someone should test it just in case, of course. But the important part is that the bundled package stays installed. You asked why we can encourage people to upgrade said packages freely. One answer is that they have a safety net. >>> IOW, shouldn't packages have some "stability gradation" that is >>> visible when users look at the list of packages via package.el? >>> Shouldn't we allow users to tell package.el which stability they want >>> to download, so that unstable packages don't inadvertently get >>> installed and mess up their production environment? >> >> We have elpa and elpa-devel. The latter is "explicitly unstable" and the >> former is "checkpoint releases". > > So what is the stability measure of "elpa", again? Is it on par with > the Emacs's release branch? Could it be? It's more stable than 'git clone' but less stable than using a release. And this will stay that way while we're using it to help stabilize package versions, too. > If not, why not? I don't think we want ELPA to have the same frequency of package releases as Emacs itself. We could add a new archive, though. Like elpa-very-stable. Which would be pushed, for example, the same versions of bundled packages that go into Emacs releases. Or something like that. >> Neither keeps the previous versions around, so it's not like the user at >> any point could make a choice to install a minor version update instead >> of going up a full major version. > > That in itself is a serious deficiency, IMO, and we should fix it by > providing the "downgrade" option. Doing that for every package will mean more work for everybody around, and it'll also increase the costs of hosting packages considerably. >>> I don't see what development pace has to do with this issue. If a >>> package is being developed at a high pace, it might mean that the >>> stable version will lag more. But what does this change in principle? >> >> It matters when we're talking not about simple additional, optional >> features, but about changes that keep pace with the evolution of the LSP >> standard, with new LSP servers that arrive, new changes in existing >> protocols. Things that users come to expect to be able to use now, and >> not in 3 years. > > Users who must have these features (presumably because they must use > servers which require that) will have to give up some stability > expectations. Exactly like users who must have some new enough > feature of Emacs which is only available on the master branch. > > So once again: what is fundamentally different or new about packages > which develop at fast pace, in the context of this discussion? Why do > we need to bring up those details here? It's an issue of whether a "stable" Eglot could actually be useful 2 years later for most people. If not (I admit I don't know for certain), we should choose to focus on other scenarios and needs, and less on stability in this particular case. >> Taking a conservative stance can work when the ecosystem supports it >> too. E.g. if every LSP server that we support now had an implicit >> promise to be properly maintained for 3 years since, at least. I don't >> think that's the case. Almost every one could be deprecated in that time >> frame, with community being recommended to switch to a newer one. > > How does this help us move forward with the discussion and with > handling this issue? Conservative doesn't mean stupid; if some > external factor changes outside of our control and forces us to make > potentially destabilizing changes, what else can we do that requires a > discussion? No, I don't think that conservative means stupid. I am fairly conservative in some things, just not in others. Or take Joao: he's at the moment being conservative about how the users install Eglot and have had it upgraded over time when using all previous releases of Emacs. > And how does it impact what we should do about > categorizing package releases according to their stability and about > the decisions which version to bundle with Emacs? No, that's a different question. One I had hopefully addressed above. >> To clarify: I made that suggestion from the premise that we do expect >> and encourage a fair fraction of the users to use just the versions of >> Eglot and Eldoc that come with Emacs 29, and never upgrade to the latest >> ones. > > AFAIU, João is of the opposite opinion: he thinks that most Eglot > users will want the latest version on ELPA, or at least a version that > is newer than the one bundled with Emacs. I am of the above opposite opinion as well, but I can appreciate your POV as well, I think. And, well, if the ultimate decision is made using the latter principle, we still could make the most of it. >> And as per above explanation, Eglot 0.14 depends on Eldoc 0.14.0 not >> because it's the very latest and spiffiest version, but because it needs >> a particular feature from it. > > And there's no reasonable way of adding to Eglot 1.14 some fallback or > compatibility shim to remove that dependency? Everything's possible. It might not even be too hard. But if we're talking about the improvement I was eyeing (better eglot<->eldoc behavior all around), then a simple shim won't cut it.