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 14:50:51 +0300 Message-ID: <86r09jddgk.fsf@gnu.org> References: Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="5668"; mail-complaints-to="usenet@ciao.gmane.io" Cc: yandros@gmail.com, emacs-devel@gnu.org To: "Martin Edstrom" Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Mon Sep 16 13:51:48 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 1sqAGh-0001HL-Rr for ged-emacs-devel@m.gmane-mx.org; Mon, 16 Sep 2024 13:51:47 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1sqAFu-0000hO-5o; Mon, 16 Sep 2024 07:50:58 -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 1sqAFs-0000hC-U3 for emacs-devel@gnu.org; Mon, 16 Sep 2024 07:50:57 -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 1sqAFr-000636-8L; Mon, 16 Sep 2024 07:50:55 -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=6fUnUqaH4A9aR8oceDTSZosqAts2NSGNVPYc2W6qbYM=; b=KPutlBdGLhHz hZRJGujngKpX6fQEI3K9oWvK2plE23+MkB7BbZUA3VLSKCzg2XWsTVZLnLJDODjZJPj2jlH5krOLA Iw4P6M2KY/ZpcEimOXzst05kP6OBaIgBhjaWRIdmEVLeYV4LmN0uVRdZgoNVfWEZZ/4jjXibtemGj +kTjT0IaafxkNlPqxqMbJ/EBQ/9Rp6XHpbJURQRwc/IvjucwN70sPB/LSDbcfsaT6nSm7fLVmfh20 GevJw36yxVim8HXNm8PjRRJhmMK4xBdzrrWHKbhwmzVTzxQs4O8lAnHCapRU2N+w3gxc/1V3gyVgI XgE3Q/ihbOf0UU6lOlbIIA==; 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:323660 Archived-At: > From: "Martin Edstrom" > CC: "emacs-devel" > Date: Sun, 15 Sep 2024 23:09:05 +0200 (CEST) > > The "catastrophe" would be a situation such as: > > - In 2020, Developer releases Package for the first time > - In 2021, Developer tires of bumping Package-Version, leaves it at 0.9 > - In 2024, Package is now at 2.2 according to the convenient git/hg tag, or maybe it has no official version beyond just "0.9.0.50-git" 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.) > - User installs Package using (use-package :vc) > - User gets the version from 2021 > - It doesn't seem to work > - 10 such users give up on Package > - The 11th user files the bug reports > - Bug reports are strange and make no sense > - User and Developer finally figure out that it's because the user used (use-package :vc) which fetched the 2021 version In any case, I wonder why the above mess you describe is not the fault of the package developer, but of Emacs? It makes little sense to be, TBH. > 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.