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

[Eli Zaretskii <eliz@gnu.org>]

> From: "Martin Edstrom" <meedstrom@runbox.eu>
> CC: "emacs-devel" <emacs-devel@gnu.org>
> Date: Sun, 15 Sep 2024 21:46:32 +0200 (CEST)
> 
> > Bottom line: I think no catastrophe happens if Emacs 30 is released
> > with the current default value of use-package-vc-prefer-newest.  It's
> > a user option, so customizing it is easy for people who want the
> > latest commit.  Even if we are making a mistake (for reasons we will
> > learn later), first time you do something there are always some rough
> > edges, so we can be excused for not realizing something due to lack of
> > experience.
> > 
> > Thanks.
> 
> Thanks for engaging!
> 
> (What is TRT?)

The Right Thing

> 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.

> 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.