From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= Newsgroups: gmane.emacs.bugs Subject: bug#62720: 29.0.60; Not easy at all to upgrade :core packages like Eglot Date: Wed, 19 Apr 2023 19:27:11 +0100 Message-ID: References: <87a5zj2vfo.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> <06d29dbd-0b33-8698-bcb8-c89368612f54@gutov.dev> <252e77fb-9657-a5be-2e86-234f7b05d162@gutov.dev> <83edog84cm.fsf@gnu.org> <8e73ca15-00a3-2082-2dd4-94585a3aa64b@gutov.dev> <83zg737szu.fsf@gnu.org> <83wn277r5p.fsf@gnu.org> <83sfcv7nx9.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="40775"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 62720@debbugs.gnu.org, rpluim@gmail.com, philipk@posteo.net, dmitry@gutov.dev, monnier@iro.umontreal.ca, larsi@gnus.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Wed Apr 19 20:28:19 2023 Return-path: Envelope-to: geb-bug-gnu-emacs@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 1ppCXS-000AP8-U7 for geb-bug-gnu-emacs@m.gmane-mx.org; Wed, 19 Apr 2023 20:28:19 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ppCXF-00031o-KK; Wed, 19 Apr 2023 14:28:05 -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 1ppCXE-0002zz-QP for bug-gnu-emacs@gnu.org; Wed, 19 Apr 2023 14:28:04 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1ppCXD-0006zV-IG for bug-gnu-emacs@gnu.org; Wed, 19 Apr 2023 14:28:03 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1ppCXC-0004PT-B6 for bug-gnu-emacs@gnu.org; Wed, 19 Apr 2023 14:28:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 19 Apr 2023 18:28:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 62720 X-GNU-PR-Package: emacs Original-Received: via spool by 62720-submit@debbugs.gnu.org id=B62720.168192885216908 (code B ref 62720); Wed, 19 Apr 2023 18:28:02 +0000 Original-Received: (at 62720) by debbugs.gnu.org; 19 Apr 2023 18:27:32 +0000 Original-Received: from localhost ([127.0.0.1]:35818 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ppCWh-0004Oe-Uu for submit@debbugs.gnu.org; Wed, 19 Apr 2023 14:27:32 -0400 Original-Received: from mail-oo1-f44.google.com ([209.85.161.44]:54537) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ppCWe-0004OQ-Qo for 62720@debbugs.gnu.org; Wed, 19 Apr 2023 14:27:30 -0400 Original-Received: by mail-oo1-f44.google.com with SMTP id 006d021491bc7-5424b046c6bso5585eaf.1 for <62720@debbugs.gnu.org>; Wed, 19 Apr 2023 11:27:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1681928843; x=1684520843; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=cIXUUwATuiCpLaM+YoFI+NBgGQdQPMux0YBMVxX0lkQ=; b=pt0eVCgHmqPwP2omjtPzOJoaSWQqDkAQPKZjq2gmzUz3NYlkoWFpshKlHYKWflypXY BWE1mZr8Yyb6M5glghKIeKJnYUjGavF9rIexFwSH9K4HzZ9BdxUOB3WPrZzGDjgvC3Fs oxrngJgZbIwMyEXBYcq74QAm5oNPtvIKd3sDv5G9ZRlkZQqiVWSGq77itXPf0dJKmOgw ET1uZR+0GA9tC96MRIbG7mAie3Xa98Z8cU4SVh3IM6VlSU1WpUiWTFeNcefS1+peMUvh Hkfab3tDwELBLTksWIng91hZPWO7FMRkZBI8AZY5IdL5WvAfjJo4LXQ85Jsdqqz8NYaN jhFw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1681928843; x=1684520843; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=cIXUUwATuiCpLaM+YoFI+NBgGQdQPMux0YBMVxX0lkQ=; b=kAHkKLOjkImzzZ0iLeC4N++a7SOE1GSvYx8ERB5d9NWOM3sClnSBaj7Ti55juOpj/z /UtG0uOQ1KPcFivjUr0hKHM5DlSGjgMqh0L9rMptZQhI7FISONWRr2D8dhQa5Jl5EX03 rYwNb7kT1BLzSDPeuVMXC7I+jD3jkHCAwg+osldCeA7hnFs0w1aGhnVoCHy4vJvxoS0M CpN67CwxVaxvzCuybH/U3f6/7BO3d0uLhEI0IrV3y+4FRsOur3MFLbxw6Lr6zM8Do7pe dT7hISD99mDnsvcOiz/buDdTiE3+kvmVpvhTAXK+tYaWRsrHL/sJwSiRnpC4b6TIXPCH vhIg== X-Gm-Message-State: AAQBX9dBRxB4rpp20AbUYgVfb75K//a/nth8ct2PInj598CunboOv72y JwrDfQr3b6VC4AwgOZpLZzcpCEExrfsAM6iJy+I= X-Google-Smtp-Source: AKy350bLUDqZTtjldN8FLeRB1mMswgVoF86yC9Y+eFXj8iFbsi5QuPq1SYRwqhE9bim7xlhQJ8VxwSy6jplz6dFBZqs= X-Received: by 2002:a05:6808:b35:b0:378:2b0c:493f with SMTP id t21-20020a0568080b3500b003782b0c493fmr3094966oij.19.1681928842891; Wed, 19 Apr 2023 11:27:22 -0700 (PDT) In-Reply-To: <83sfcv7nx9.fsf@gnu.org> X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.bugs:260289 Archived-At: On Wed, Apr 19, 2023 at 6:59=E2=80=AFPM Eli Zaretskii wrote: > > > From: Jo=C3=A3o T=C3=A1vora > > Date: Wed, 19 Apr 2023 18:27:08 +0100 > > Cc: dmitry@gutov.dev, rpluim@gmail.com, philipk@posteo.net, > > 62720@debbugs.gnu.org, larsi@gnus.org, monnier@iro.umontreal.ca > > > > On Wed, Apr 19, 2023 at 5:50=E2=80=AFPM Eli Zaretskii wr= ote: > > > > > > This just doesn't make any sense to me. Can't you understand that = other > > > > maintainers also value stability for their packages? > > > > > > Of course I can. But once again: if Eglot 1.14 is not stable enough, > > > > Stable enough for whom, or for what? Stability is quantity in a spectr= um. > > Stable for us. We are not talking about absolutes here, we are > talking about relative stability. I'm saying that if some package is > stable enough to be used with Emacs version X.Y, it is by definition > also stable enough to be included in Emacs version X.Y. The relative > stability levels of these two cases must be the same, or else we are > inconsistent in our own judgment of stability. > > > I think Emacs releases should come with the most well tested code. No > > program is perfect. Eglot 1.14 is stable, but it's not _as_ stable as = Eglot > > 1.12 because the latter has seen more testing? > > Then how come we tell users of this same Emacs 29 to update to Eglot > 1.14 without too much thought? And you even insist on making that > automatic when packages are updated at startup. Won't that > destabilize their Emacs? I don't dictate to users how much to think :-) I just assume that they've been thinking about it in Emacs 28, and they are happy with this amount of thinking, else they would be complaining about stability, and they aren't. Maybe some users are holding on to Emacs 26.3 + Eglot 1.0 for dear life, who knows? It's very simple to me. To summarize and to hopefully answer the question that you repeatedly put before me, this is my recommendation to users: "Dear user, Emacs 29 will come with the most stable version I can offer, and I can tell you, prospective user, that it has been through as much of the Emacs 29 pretest period as possible. If you, prospective user, are interested in the features listed in etc/EGLOT-NEWS, you may try upgrading to the latest version (I hope it will be easy, good luck!) In the unlikely event that things go sour for your particular LSP server and use case, you have my deepest apologies, and you should revert back to the version bundled with Emacs 29. Thank you, Your maintainer" The second part of this recommendation is what I've always recommended. I've never had to phrase it like this, but this has always been my recommendation. > No, I suggest that you make changes on master so that these problems > are avoided in the first place. Changes in a core package on the > Emacs master branch should be done while keeping in mind that this > same version of a package will be on ELPA and users of older Emacsen > will install that newer version. So the newer version on master > should avoid making changes which would mandate newer versions of > other packages, by providing the necessary compatibility fallbacks. So, if I want to do a feature on master that depends on some new infrastructure on package X that appeared on master (say Xref's upcoming support for "find any type of thing declaration/macro/etc"), I have to do no less than duplicate that new infrastructure in Eglot.el and do a runtime check. That's... not good, to say the least. But noted. Now I (think I) understand what you suggest. AFAICT basically suggesting all Package-Requires are eliminated, to get rid of package.el dependency system. You should argue for that in emacs-devel explicitly so, I think, because that will probably elicit some interesting reactions from :core package developers. "Package-Requires" is used liberally now AFAIK It's the most basic underpinning of Eglot's design philosophy, if there such a thing. That's why Eglot is called "minimal". It's not minimal in functionality! It's minimal in size and complexity because it reuses code and keeps itself simple. And if I may be a bit less humble about it, I've gotten a few compliments about it. Jo=C3=A3o