Re: Reconsider defaults for use-package-vc-prefer-newest

[Eli Zaretskii]

> From: "Martin Edstrom" <meedstrom@runbox.eu>
> CC: "emacs-devel" <emacs-devel@gnu.org>
> 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.