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

[Martin Edström]

On Mon, 16 Sep 2024 14:34:55 +0300, Eli Zaretskii <eliz@gnu.org> wrote:

> > While the option is a new thing in Emacs 30, use-package :vc itself is a 
> > new thing in Emacs 30, so it is not as if there is an old behavior to 
> > emulate.  I should also point out that the module it was inspired by, 
> > vc-use-package, actually had the opposite default!  So, that setting has 
> > already been tested by lots of users on Emacs <29, and it is Emacs 30 that 
> > will change things.
> 
> Yes, you said that in your original message, and I understand that
> argument.  But as I responded, I'm not convinced the two options must
> always be in sync, as they are used differently for different purposes.

Okay, I'll accept that for the command package-vc-install as I have not thought 
much about its use cases.  I want to call attention to the old use-package :vc, 
shippedwhich had the confusing vc-use-package [1].  The Emacs 30 use-package 
:vc is a drop-in 1:1 replacement  This thing:    It had the opposite default 
from the one Emacs 30 is about to have.

> 
> > Anyway. If that's not good enough, maybe we can test the new setting in 
> > Emacs 31, and backport to Emacs 30.2 in the future.
> 
> Yes, that would be one way forward.  Especially if enough users come
> to us asking to flip the default, and explain why.
> 
> > I should also point out that the catastrophe occurs not at release time, 
> > but years afterwards, when we're on Emacs 31, 32, 33... but devs still want 
> > to support Emacs 30, getting worse with time. So I do hope that it will be 
> > possible to change a setting like this with Emacs 30.2 or some other 
> > "bugfix" release.
> 
> There's no reason to do this for user options, since customizing an
> option if the user doesn't like its default is easy.
> 
> > As for making devs get their act together, sure, they could do that. But 
> > three problems with that attitude:
> > 
> > 1. It makes sense to impose requirements on devs who are submitting 
> > packages to NonGNU Elpa, but this setting affects everyone, including those 
> > who have not opted in to such requirements.
> > 2. Not every dev will get the memo, naturally, and the ones who get hurt in 
> > the meantime are users, who believe that the dev's package is broken when 
> > it is not (and the dev should not be punished for being out of the loop).
> > 3. The devs who do get the memo, and were previously content with a frozen 
> > Package-Version, will resent GNU for forcing what they perceive as a 
> > workaround. I do not think that is worth it.  Like it or not, MELPA has 
> > allowed many of us to taste of the convenience of git/hg tags, and it 
> > didn't use to be a problem... until Emacs 30. Now they have to adopt some 
> > toolchain like sisyphus.el and pollute the commit log with two extra 
> > commits for every new version, to solve what used to be a non-issue.
> 
> I consider advancing Package-Version when significant changes are made
> a simple and uncontroversial thing to do for any package developer.  I
> cannot imagine why someone who wants their package in good shape to
> regard this as some annoyance.