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: Thu, 20 Apr 2023 12:47:50 +0300 Message-ID: <83sfcu6g1l.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> <83a5z482e3.fsf@gnu.org> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="4307"; 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 Thu Apr 20 11:48:06 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 1ppQtY-0000sZ-El for ged-emacs-devel@m.gmane-mx.org; Thu, 20 Apr 2023 11:48:04 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ppQtA-0006LX-B6; Thu, 20 Apr 2023 05:47:40 -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 1ppQt8-0006L8-Pr for emacs-devel@gnu.org; Thu, 20 Apr 2023 05:47:38 -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 1ppQt8-0007sy-HO; Thu, 20 Apr 2023 05:47:38 -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=a+S7+qMv42XQjC7W+y/7XiqFS6Sscb4PzBeowuiVeck=; b=mO7JsIQWG1CF u3GeEMZCVWsocJXWePScCDfASocZe+uorsnJVc9Szxr+dobWjw5gisYIB3ddrRmjFbqOVyOQ70iqz 3mGi02KumtZX0g/dmzLtONrkqHbrx/qQEXrINnbZ6nRgaSPv8taEvHj2P9+zo0KSTdbjth+eZw3rF WGZFOCds70fOfd50148DOoR2RJCCtqGpSGagy3wZgzcMgxk0MCJURFsJvUSvtSGv6Hb4W6yIzOexN FieFmQlJ7cQwDo2EH04dffeix4OOjKzID4TCbqWyrSBr89P7bq17PEIKZL9tXzMJVhrswimIxR8Ii uvO9d97L3Vhphn7NEQZV7w==; 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 1ppQt8-00050I-1Z; Thu, 20 Apr 2023 05:47:38 -0400 In-Reply-To: (message from Dmitry Gutov on Wed, 19 Apr 2023 22:25:08 +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:305495 Archived-At: > Date: Wed, 19 Apr 2023 22:25:08 +0300 > Cc: joaotavora@gmail.com, emacs-devel@gnu.org > From: Dmitry Gutov > > >> 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. All those differences disappear when we are discussing core packages. Which is my only focus in this discussion. > >> 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. I very much hope it doesn't stay that way for core packages. > > If not, why not? > > I don't think we want ELPA to have the same frequency of package > releases as Emacs itself. This is a red herring. Emacs releases are less frequent because Emacs is a large collection of packages, and thus the period required for its stabilization is much longer. A single core package can apply stability criteria and still not go anywhere near the Emacs release frequency. It does need more effort on the part of the package developers, but the effect on the release frequency will be minor. > > 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. "Two years" because you think the release frequency of Eglot will be slowed down to such abysmally low value? As explained above, I think this is not going to happen, so there's no need to assume this will be the outcome.