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 17:03:49 +0300 Message-ID: <83a5z2646y.fsf@gnu.org> References: <87a5zj2vfo.fsf@gmail.com> <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> <83sfcu6g1l.fsf@gnu.org> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="3298"; 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 16:04:57 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 1ppUu8-0000dh-4L for ged-emacs-devel@m.gmane-mx.org; Thu, 20 Apr 2023 16:04:56 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ppUtD-00032M-E5; Thu, 20 Apr 2023 10:03:59 -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 1ppUtA-00032C-KD for emacs-devel@gnu.org; Thu, 20 Apr 2023 10:03:56 -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 1ppUt8-00081S-TH; Thu, 20 Apr 2023 10:03:56 -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=CDOqMlhAgJoywrkfhKHxs/u6+J+ITlyZnWVLgFRyRmI=; b=qqTCN8R6+QH5 rUkBTk4k2giDJ8rMuGNfmu36uQ8STcT7JbPp7Kvvr9tmjYfeccbFHJxcD37htaoPpum3xlSx4umDW BE02Nu7dIE5bxx8wzgZ9aeDLQYM9XLxgeaOx47lJEsIBa0cTBndDoORzPxF2gqteava4K4FmvAf+L e62r1Z+DvvsyHUSwrf1R0CLfa7QEVhUYyVQ6P530mEjTWEZwemzxu3Om/V5zmi9gGR8Zf2H+pvj8N ZG/v9bxyxjQX0NSzTwgD2Yvg9SuQ9+PfGLTh1YKYvYfTDQsaM4iybjwjFUFNzyXYo8xKdOJs+xSAR a69K2JtrrWglLMPWpJhI8w==; 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 1ppUsp-0007ju-EQ; Thu, 20 Apr 2023 10:03:51 -0400 In-Reply-To: (message from Dmitry Gutov on Thu, 20 Apr 2023 16:03:16 +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:305510 Archived-At: > Date: Thu, 20 Apr 2023 16:03:16 +0300 > Cc: joaotavora@gmail.com, emacs-devel@gnu.org > From: Dmitry Gutov > > On 20/04/2023 12:47, Eli Zaretskii wrote: > > >>> 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. > > Disappear, why? The core packages are the only kind of "bundled" > packages we have (for now), and so they are the only ones that can be > safely reverted to the bundled version via uninstallation. Exactly. That answers your 'why?" question, AFAICT. > Let me try again: one of the uses of ELPA is to push out the package > release "into the real world" so that more people can test it. > > So that "N weeks later" we can consider is "stable" and be content to > have it in an Emacs release. > > By the very definition, the same release wasn't "stable" N weeks ago, > just as it was published. So ELPA cannot be considered to have the same > level of stability because we also use it for testing this way (among > other things). Perhaps there's some kind of misunderstanding here. To me, declaring a version of a package "stable" just means some label in its metadata, which is exposed to package.el and to the users. So when the package developer decides that "N weeks have passed", he or she will add that label, thus making the corresponding version be considered "stable". Next time users check for updates they will see that, and could then upgrade to the "next stable" version if they so desire. IOW, the version on ELPA that wasn't "stable" before, and was used for testing, now becomes "stable". Am I missing something here? > But note that as per above, if we wanted ELPA to be the "stable" source, > we'd need some other testing ground before pushing releases to it. For core packages, that testing ground is the master branch. Exactly as for code in Emacs itself. Once a version is declared "stable", its changes will be cherry-picked to the Emacs release branch, thus making it part of the future bug-fix release. > E.g. > we could just wait for people using the master branch to report > problems. But since there are fewer of them than there are ELPA users, > it stands to reason that the stabilization periods must become longer. > Maybe not two years, but longer than with ELPA. Why do you assume that people who use the Emacs master branch don't use core packages? or that there are fewer of them than those who use the release branch? And, since the code of the core package that is on master is also on ELPA, I don't see how we can lose any testing, because reports from users who use non-"stable" versions from ELPA are as good as from those who use the package via the builds of the Emacs master branch. So nothing is lost here, not that I could see. > >>> 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. > > No, no. I'm talking the scenario with users who are going to stay with > the version of Eglot that comes with Emacs 29, for two years without > upgrading. That might not be wise in a lot of cases (admittedly, this is > just a guess at this point, looking at the speed of changes around the > community), so we should make it easy to upgrade. > > I don't believe the upgrade must be made automatic, however. Users of Emacs 29 that need a newer Eglot don't need to stay with the version we shipped. First, if the machinery to promote Eglot versions to "stable" status is in place, bug-fix 29.x releases could have newer versions of Eglot bundled with them; our rate of putting out bug-fix releases is much higher than once every 2 years. Users who cannot wait until the next bug-fix release, but still want stability, will be able to upgrade their Eglot to a newer version, provided that we mark some newer version on ELPA "stable" after "N weeks" or so. Finally, users who want newer Eglot badly and are willing to sacrifice some stability will update to the latest-and-greatest version on ELPA, even if it is not "stable" yet. So I don't see how this can lose, if we indeed have the above system, or something like it, in place.