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 15:47:32 +0300 Message-ID: <83a5z482e3.fsf@gnu.org> References: <87a5zj2vfo.fsf@gmail.com> <87leiwdyff.fsf@posteo.net> <834jpk5hih.fsf@gnu.org> <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> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="4237"; mail-complaints-to="usenet@ciao.gmane.io" Cc: joaotavora@gmail.com, emacs-devel@gnu.org To: Dmitry Gutov Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Wed Apr 19 14:48:13 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 1pp7EL-0000sB-FZ for ged-emacs-devel@m.gmane-mx.org; Wed, 19 Apr 2023 14:48:13 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1pp7Dc-0002j2-QX; Wed, 19 Apr 2023 08:47:29 -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 1pp7DX-0002eE-U7 for emacs-devel@gnu.org; Wed, 19 Apr 2023 08:47:24 -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 1pp7DX-0002Hk-Al; Wed, 19 Apr 2023 08:47:23 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-version:References:Subject:In-Reply-To:To:From: Date; bh=Znf9GPhUe4/wvMlHEOAzVvcH+3LtCqZxJUC8o7pdDXY=; b=DNRMxBHG/gmrSF1CV8Fl b2PAg7QGfzcU/w7ZrzRzzoc/7BE2QsmNdSqn2jkfmJVf/pmPiLeP2TBQSzaxnOWyoXESEA/ZYbCx2 IuA7Hkv9rMS9D/6KKOErEDD5FW0iWIj3p8Qxi6f2/PNXmzTp8PadXEHfMmHbBe1IcsPr+4o2ZN3j1 CurFBrVroMrpiEmjoiCygHKnSpeZqxBH54zn9zvh8/KKxaHm5npwIxeWYgHkmzFlL7gedxhQ6On4S JZQmXVI7ytoy2TUZDxOfwGP4VhtJQYY1G7oWzPVSwMOWCVYJ2xbnk2aUeA5TeJ0pG1/7EKgEppnno 08EXhKqr/rYI/A==; 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 1pp7DW-0004U5-Or; Wed, 19 Apr 2023 08:47:23 -0400 In-Reply-To: (message from Dmitry Gutov on Wed, 19 Apr 2023 01:10:56 +0300) 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:305433 Archived-At: > Date: Wed, 19 Apr 2023 01:10:56 +0300 > Cc: joaotavora@gmail.com, emacs-devel@gnu.org > From: Dmitry Gutov > > > 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. > 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. > > 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. 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. 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? > > 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? If not, why not? > 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. > > 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? > 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? 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? > 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. > 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?