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

[Eli Zaretskii <eliz@gnu.org>]

> From: "Martin Edström" <meedstrom@runbox.eu>
> CC: "yandros" <yandros@gmail.com>, "emacs-devel" <emacs-devel@gnu.org>
> Date: Mon, 16 Sep 2024 18:46:48 +0200 (CEST)
> 
> On Mon, 16 Sep 2024 14:50:51 +0300, Eli Zaretskii <eliz@gnu.org> 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.