From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Dmitry Gutov 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 16:03:16 +0300 Message-ID: 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> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="2553"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.10.0 Cc: joaotavora@gmail.com, emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Thu Apr 20 15:04:22 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 1ppTxU-0000SI-Um for ged-emacs-devel@m.gmane-mx.org; Thu, 20 Apr 2023 15:04:22 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ppTwi-0005XV-Cb; Thu, 20 Apr 2023 09:03:32 -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 1ppTwc-0005PX-Kh for emacs-devel@gnu.org; Thu, 20 Apr 2023 09:03:26 -0400 Original-Received: from wnew2-smtp.messagingengine.com ([64.147.123.27]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ppTwZ-0007Ii-O2; Thu, 20 Apr 2023 09:03:26 -0400 Original-Received: from compute2.internal (compute2.nyi.internal [10.202.2.46]) by mailnew.west.internal (Postfix) with ESMTP id 6D94E2B066D8; Thu, 20 Apr 2023 09:03:21 -0400 (EDT) Original-Received: from mailfrontend2 ([10.202.2.163]) by compute2.internal (MEProxy); Thu, 20 Apr 2023 09:03:21 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gutov.dev; h=cc :cc:content-transfer-encoding:content-type:content-type:date :date:from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:sender:subject:subject:to:to; s=fm2; t= 1681995801; x=1681999401; bh=hRIQtnDLjsod2X0KH9NIsGe/QnU8+KPbpij OjdPCe3M=; b=IeytEhoJVwbNYtsUcMiNBsHmpA4vHqdbMv/GGwsC/luCJm3WVnZ HM78Icr2EsouME4z9ejwGyzA6QJKA4rFCP7YkxBC+1aLm6gsT06VH2nOFXOMhyv1 yh2CBQVvglfFT46SXXeTVvXbs6kjkLf40sBF4z7YzVS2FHLxDZRoLtk4NfWnCRJH dHOrxBBRgy/K7nCBDz5K5bC6VfE2pC/bZszpEfXzXWtSLRQEwfPR6JKkH9ugaEkS ou1S805BFkITlt/CXL0JC0C1P6RqA/NkwH7hU8Sg7KCkxCrW/SB+fM+pzsmbMFiF 9Xb+i2ywP1O0eUJFZ0k6EIE7HMLLq/3g1oA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:content-type:date:date:feedback-id:feedback-id :from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:sender:subject:subject:to:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; t= 1681995801; x=1681999401; bh=hRIQtnDLjsod2X0KH9NIsGe/QnU8+KPbpij OjdPCe3M=; b=JFQ4eNtpLcvrmL3xshY0KnABqVkzX5TPmvRKUoRaq8etAR08MDT KfAtGuvRFSceE9Ku3q/SSVtZmff/P3nySpPfuP9o0fWYXS0xPIYMhAnvvclFjXVq xaFeTeRY34FGQv47fzMo+CM6Jpbn7QVgwz2TZf5gkCA5JdC8OMJ87kBhd2JmNsMA TDkaIptBM+JyPseRYuzkUcqydytuE5fcx+HiQ57+BNbEx0FRzMvZ+mVh/+bOQCWC PFJM7fYG1voOWQu2rciK7K/tlkgK5mOkU0N1gKkQte0vnNd9j1SRilZBydxjbL2v VuoNNxg6O3CRshKKYcDRlJ/mo5MfQKGJGtw== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvhedrfedtvddgheekucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepkfffgggfuffvvehfhfgjtgfgsehtjeertddtfeejnecuhfhrohhmpeffmhhi thhrhicuifhuthhovhcuoegumhhithhrhiesghhuthhovhdruggvvheqnecuggftrfgrth htvghrnhepiefgteevheevveffheeltdeukeeiieekueefgedugfefgefhudelgfefveel vdevnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepug hmihhtrhihsehguhhtohhvrdguvghv X-ME-Proxy: Feedback-ID: i0e71465a:Fastmail Original-Received: by mail.messagingengine.com (Postfix) with ESMTPA; Thu, 20 Apr 2023 09:03:19 -0400 (EDT) Content-Language: en-US In-Reply-To: <83sfcu6g1l.fsf@gnu.org> Received-SPF: pass client-ip=64.147.123.27; envelope-from=dmitry@gutov.dev; helo=wnew2-smtp.messagingengine.com X-Spam_score_int: -44 X-Spam_score: -4.5 X-Spam_bar: ---- X-Spam_report: (-4.5 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-1.669, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=ham autolearn_force=no X-Spam_action: no action 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:305503 Archived-At: 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. >>>> 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. 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). >> > 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. I guess you're right. 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. 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. >>> 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.