From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: emacs@mohsen.1.banan.byname.net Newsgroups: gmane.emacs.devel Subject: Re: Stability of core packages Date: Fri, 28 Apr 2023 22:21:46 -0700 Organization: ByStar Federation of Autonomous Libre Services -- http://www.by-star.net 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> <83r0sh8i1q.fsf@gnu.org> <35638c9d-e13f-fad8-5f95-ea03d65d4aa2@gmail.com> <87a5z3izst.fsf@web.de> <83v8hr7qk9.fsf@gnu.org> <871qkfirbl.fsf@web.de> <83ildr6qhu.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="39321"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.1.50 (gnu/linux) Cc: "Dr. Arne Babenhauserheide" , joaotavora@gmail.com, jporterbugs@gmail.com, dmitry@gutov.dev, emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sat Apr 29 07:29:59 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 1psd9i-000A5A-R3 for ged-emacs-devel@m.gmane-mx.org; Sat, 29 Apr 2023 07:29:58 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1psd8z-0004tp-1G; Sat, 29 Apr 2023 01:29:13 -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 1psd1v-0004Hk-S5 for emacs-devel@gnu.org; Sat, 29 Apr 2023 01:21:55 -0400 Original-Received: from 0030.bacs.by-star.net ([198.62.92.180] helo=0027.bacs.by-star.net) by eggs.gnu.org with smtp (Exim 4.90_1) (envelope-from ) id 1psd1s-0004aR-DS for emacs-devel@gnu.org; Sat, 29 Apr 2023 01:21:55 -0400 Original-Received: (qmail 28660 invoked from network); 29 Apr 2023 05:21:47 -0000 Original-Received: from 192.168.0.90 ([192.168.0.90]) by 0030.bacs.by-star.net ([198.62.92.180]) with ESMTP via TCP; 29 Apr 2023 05:21:47 -0000 In-Reply-To: <83ildr6qhu.fsf@gnu.org> (Eli Zaretskii's message of "Thu, 20 Apr 2023 09:02:05 +0300") Received-SPF: none client-ip=198.62.92.180; envelope-from=emacs@mohsen.1.banan.byname.net; helo=0027.bacs.by-star.net X-Spam_score_int: -14 X-Spam_score: -1.5 X-Spam_bar: - X-Spam_report: (-1.5 / 5.0 requ) BAYES_00=-1.9, KHOP_HELO_FCRDNS=0.4, SPF_HELO_NONE=0.001, SPF_NONE=0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=no autolearn_force=no X-Spam_action: no action X-Mailman-Approved-At: Sat, 29 Apr 2023 01:29:10 -0400 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:305703 Archived-At: I have been following this thread from a meta perspective. The essence of the difficulty is that we are following an established pattern that has various weaknesses and we are now trying to adjust that pattern. What I am suggesting breaks the existing model. Let me start with some context. Because we use git for everything and because it is possible to take complete git snap shots of all relevant packages, it is possible to easily provide stability for the user based on snapshots. Consistent upgrades are then possible for new consistent git snapshots. So, based on the snapshots the packages are not stale and remain consistent while evolving. This is what doomemacs does. For every package, there is a git tag which doomemacs keeps with the adoption of the package. The tags are guaranteed to be consistent. With Blee (ByStar Libre Emacs Environment) I do the same but instead of keeping that tag with the packages, I keep central manifests for emacs releases. So, emacs-28.1 has its own packages manifest which can be upgraded from time to time. All upgrades go to the appropriate repo and get the appropriate tag based on the manifest. I do this across all emacs package archives -- which I see as collections of git repositories. If you want to go with something like this, you have to revisit the package retrieval model. For every release of emacs, you maintain a separate manifest. And you keep updating that at new releases and even in between releases. Since all emacs archives are git based, it is possible to apply this strategy to all of them -- where each take care of its own consistency. In practice, this has already happened for layers that sit on top of emacs (doomemacs, blee). It is a matter of adopting the higher layer model in the core. There are already many variations on the model of packages.el. If you want to go with this model, much needs to be revisited. But much will be gained. Again, these comments only deal with the meta topic not the at hand Eglot topic. But, it shows how eglot upgrades could have rolled back to emacs-28. ...Mohsen Eli Zaretskii writes: >> From: "Dr. Arne Babenhauserheide" >> Cc: joaotavora@gmail.com, jporterbugs@gmail.com, dmitry@gutov.dev, >> emacs-devel@gnu.org >> Date: Wed, 19 Apr 2023 21:40:35 +0200 >> >> > Specifically, users of Emacs 28 and older, who had Eglot installed, >> > and expect Eglot to be automatically updated upon Emacs startup >> > whenever a new Eglot version is available, will now have their >> > expectations broken after they upgrade to Emacs 29, because Eglot is >> > now a built-in package, and package.el won't by default upgrade a >> > built-in package. >> =E2=80=A6 >> > So there's a dilemma here: which of the two groups of users to break? >> >> Not updating eglot until the next Emacs release shouldn=E2=80=99t cause = breakage >> in any other packages, right? > > No, it shouldn't. With the obvious exception of the breakage that is > already part of the current Emacs release, which we somehow failed to > detect and fix before releasing it. > >> Except if a more modern eglot is a dependency of a non-built-in package. > > Right. > >> I think that=E2=80=99s what I would prefer: I would treat being pulled i= nto >> Emacs as a stabilization step that switches the package from being on >> the latest version to being at the version in Emacs or the minimum >> version required by dependencies =E2=80=94 if that version is higher tha= n the >> version in Emacs. Basically minimize the distance from the Emacs >> release. > > AFAIU, that is what will happen with Emacs 29 when it is released. > But things might change in Emacs 30, as we are currently discussing > what needs to be done to better support updating core packages.