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: Stability of core packages (was: Not easy at all to upgrade :core packages like Eglot) Date: Tue, 18 Apr 2023 15:57:05 +0300 Message-ID: <83r0sh8i1q.fsf@gnu.org> References: <87a5zj2vfo.fsf@gmail.com> <83wn2h5825.fsf@gnu.org> <87wn2gkhzr.fsf@posteo.net> <83cz485oxi.fsf@gnu.org> <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> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="38199"; 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 Tue Apr 18 14:57:41 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 1poktx-0009kD-AJ for ged-emacs-devel@m.gmane-mx.org; Tue, 18 Apr 2023 14:57:41 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1poktI-0007RX-HW; Tue, 18 Apr 2023 08:57:00 -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 1poktG-0007RM-CB for emacs-devel@gnu.org; Tue, 18 Apr 2023 08:56:58 -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 1poktF-0002b6-Se; Tue, 18 Apr 2023 08:56:57 -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=QWFiVO/iVQXS9awdm4lGlvF+ejniLVNqOKP45qt1hMM=; b=iwmhuGNPWxjv pvB3vHECZlU6mDI7Gv8ENuCX7FvT0ZgogDZ4pRmQqo3RBcIYOQcWdE2IRUaPHx9nA7LcjSec3zoxg JtiXI8AZ8ltkVsorG8hxxJMKUym86il1DcXFxeP+xzFn6lU3yVu8yKhFY2sdtsekzqR9YYOjXOtvw 1GWmwnXtiN7rAO+Xdjy3ZzOeTtSeKDhuJEn85wRy45rwEpNlJ5kMFoemjXlslsRVJivKU14Ok0+KY ncdyhVk6YjZOSTX3MCNCEGFV4Hr5GhuYJthy04DDnB2StKFhCK/45N/rr9yk0jxghocbsmCMh9qY5 x4vO14AKkvbdArjLi6sQZg==; 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 1poktF-0007RX-6D; Tue, 18 Apr 2023 08:56:57 -0400 In-Reply-To: <09a49ab9-ac72-36a9-3e68-9c633710eba7@gutov.dev> (message from Dmitry Gutov on Tue, 18 Apr 2023 04:25:01 +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:305406 Archived-At: This discussion no longer belongs to the bug tracker, so I'm moving it to emacs-devel and changing its Subject. Please reply here, not there. For those who see this for the first time, and want more background, here are some relevant messages which discussed this aspect as part of the otherwise huge thread, which is only loosely related to this particular issue: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=62720#383 https://debbugs.gnu.org/cgi/bugreport.cgi?bug=62720#398 https://debbugs.gnu.org/cgi/bugreport.cgi?bug=62720#401 https://debbugs.gnu.org/cgi/bugreport.cgi?bug=62720#410 https://debbugs.gnu.org/cgi/bugreport.cgi?bug=62720#413 > Date: Tue, 18 Apr 2023 04:25:01 +0300 > Cc: joaotavora@gmail.com, rpluim@gmail.com, philipk@posteo.net, > 62720@debbugs.gnu.org, larsi@gnus.org, monnier@iro.umontreal.ca > From: Dmitry Gutov > > On 17/04/2023 05:24, Eli Zaretskii wrote: > >> Date: Sun, 16 Apr 2023 23:46:37 +0300 > >> Cc: rpluim@gmail.com, philipk@posteo.net, 62720@debbugs.gnu.org, > >> larsi@gnus.org, monnier@iro.umontreal.ca > >> From: Dmitry Gutov > >> > >> On 14/04/2023 22:28, Eli Zaretskii wrote: > >>> If, OTOH, > >>> you think that it's imperative to allow_all_ users of Eglot with > >>> Emacs 29 to upgrade to Eglot 1.14 (and 1.15, 1.16, etc., when those > >>> become available), then we should release Emacs 29 with 1.14. > >> > >> Was this question about stability only? > > > > It was about the criteria for which versions of core packages to ship > > with a release. > > I don't think we can get a single set of criteria across core packages. We don't need to have just one set. Packages are different in both their complexity, their dependence on other packages, and dependence of other packages on them. So one set is unlikely to fit the bill, indeed. But that doesn't mean we shouldn't have criteria at all. We should strive to have a small number of them, and we should know which set is applicable to which class of packages. 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. > E.g. Org is developed externally, has its own community of significant > size, and does split off release branches (with additional testing, I',m > guessing). > > Eglot, OTOH, is developed only here, with no additional release workflow > other than what MELPA/GNU ELPA historically provided: collect up some > features/fixes, bump the Version header, and push a new release out to > the users. The lack of extended testing period is made up for with the > capability to push out a new fixed version overnight. That's why the > difficulty in upgrading to the latest version (for Emacs 29 users) is > going to hurt. 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? 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? > BTW, if you recall the threads before Eglot was added, I was against > that, and one of the things I cited is an LSP client has inherently high > development velocity. Maybe the LSP community will settle/mature/stop > adding features one day, but it's not there yet. 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? > >> Because since we've decided in favor of stability of package.el, and > >> against eglot's easy upgradability, I would suggest to backport Eglot > >> 1.14 to emacs-29. > > > > I won't object. In fact, I asked up front why not. > > Note that that suggestion comes with a fix to eldoc which you so far > have rejected for emacs-29. You mean, the change in ElDoc that avoids the "jumping mode line" issue? If so, it is unfortunate for Eglot to depend on that, because it means users of Emacs 29 will be unable to upgrade to Eglot 1.15 without by side effect installing a newer and potentially less stable ElDoc. (I also am surprised that change is a must for Eglot 1.15.) So this again goes back to the main issue: how should the stability considerations affect development of core packages and their "stability gradation"? Developers of core packages should keep these aspects in mind at all times, and, for example, avoid dependencies on other packages that aren't absolutely necessary. Otherwise, we will have to advise users who value stability not to upgrade their core packages for fear of destabilizing their environments, and the whole advantage of having core packages on ELPA will be effectively lost, at least for those users who want stability. IOW, having a core package on ELPA comes with some serious strings attached, and just ignoring them, or leaving that up to the users (without duly informing them about their new responsibilities) is not a good solution, IMO. We should seriously ponder these aspects, and the sooner the better.