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: Reconsider defaults for use-package-vc-prefer-newest Date: Mon, 16 Sep 2024 21:10:48 +0300 Message-ID: <86bk0ncvvb.fsf@gnu.org> References: <86r09jddgk.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="25795"; mail-complaints-to="usenet@ciao.gmane.io" Cc: yandros@gmail.com, emacs-devel@gnu.org To: =?utf-8?Q?Martin_Edstr=C3=B6m?= Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Mon Sep 16 20:11:35 2024 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 1sqGCE-0006Xe-Gl for ged-emacs-devel@m.gmane-mx.org; Mon, 16 Sep 2024 20:11:34 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1sqGBl-0000UF-FA; Mon, 16 Sep 2024 14:11: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 1sqGBg-0000Tz-LB for emacs-devel@gnu.org; Mon, 16 Sep 2024 14:11:00 -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 1sqGBf-0007Cq-Pe; Mon, 16 Sep 2024 14:10:59 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-version:References:Subject:In-Reply-To:To:From: Date; bh=VK5re3GLsPMICm+1ZfK6XGajAzDA52yZmIMQfrxACEQ=; b=ly6dn6t8iPBPPSPfEzOl u5q/CJOD0Eeo8P8m/C/+paSB7RtPDjUryprpWjnRp6K2iVtrASOnv1fCO1qH1eWyRp7W6OIaKILTJ eeHGgELWeqH2FL5jpR9uR9K2gTI/FuJ1bjYKvo0otAwEp/a/s07///zEuPOg7omMjRdyvDZnvdpCa ZEbu1yeFGE7Ln4cI1563egasldN+CKeD1fCtG345KIiz+f69p/SgawTtlrAMQzdR7XmNjF8ihDqRZ MUaQQFkZ3Lt0AiIMP/4zDPPVNG6kc2QP98AI63300E0eSKHautI3gkUr8Ibdd3DvNzsnIQaCqkS+8 weAXVA9aM9GOzQ==; In-Reply-To: (meedstrom@runbox.eu) 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:323673 Archived-At: > From: "Martin Edström" > CC: "yandros" , "emacs-devel" > Date: Mon, 16 Sep 2024 18:46:48 +0200 (CEST) > > On Mon, 16 Sep 2024 14:50:51 +0300, Eli Zaretskii wrote: > > > If the problem is that there's a tag with the correct version, but the > > Package-Version heading was not updated, we could perhaps have > > use-package :vc detect that and either display a warning or even > > automatically use the commit with the tag. Crucially, this is NOT the > > latest commit in the Git repository, it is the commit which has the > > latest release tag -- a far cry from what you suggested originally > > (apologies if I misunderstood you back then.) > > I agree it's a good way forward if you are open to look up both the Package-Version and the git tag and basically choose the highest-looking version between the two. I had somehow ruled out that option. > > What I suggested was, technically, to get the latest commit *with a given Package-Version*. > > Which need not be the same thing as the latest commit. It is also not necessarily a stable commit. It could have bugs. Installing the commit with a Package-Version heading means we don't subject users to the risk of getting a bad version, on the assumption that bumping a version means the developer announces the code as more or less stable. Looking for a commit with a release tag has the same advantage, whereas what you suggest doesn't. > The latest commit could have a pre-release version like "0.6-pre", and so (I assume...? Not sure) Emacs would walk back until finding the commit with "0.6" and check out that one. This is indeed a risk, and this is why we prefer to use Package-Version. But we could also try to look at release tags, at least as an option. > > > To counteract this would amount to a heuristic that looks up the package repository online and compares the age of recent commits with the commit fetched by (use-package :vc), but what is the threshold that you would set to trigger the warning? I don't think it is realistically doable. > > > > Why not? Detecting such suspicious "last versions" could be a good > > idea and a good service to users, and is not that hard to implement. > > But how would you do it? By looking at commit dates and showing a warning or informational message. > All it takes is a single commit to introduce changes on which another package will rely. It can be as little as one minute between the commits in question. One minute ago is not outdated in any sense of the word. In any case, this is just a warning, meant to draw the user's attention to something that he/she should look into. What to do with that is entirely up to the user. > Or conversely, a package may be mostly unchanged for years but that does not mean there is a problem. So that brings us to a bunch of UX issues to answer. Should users "dismiss" each warning individually? (Bear in mind there could be hundreds.) Should these dismissals be recorded in `custom-file` or some such location? It seems like a lot of effort to do well compared to my other suggestions, but that's just my impression. Showing a message with a 1-sec sit-for is the usual technique. The messages are logged in *Messages*, so users could look them up later. I don't see a significant problem here, sorry.