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

["Martin Edstrom" <meedstrom@runbox.eu>]

> > From: "Martin Edström" <meedstrom@runbox.eu>
> > CC: "emacs-devel" <emacs-devel@gnu.org>
> > Date: Sun, 15 Sep 2024 19:38:55 +0200 (CEST)
> > 
> > Now that we're on Emacs 30.0.91, I feel the need to call this out as a fairly release-critical bug. Perhaps I should have emailed bug-gnu-emacs, but now that'd split the discussion over two places, so I'll keep it here.
> > 
> > If this is the kind of setting we can flip in a patch release, then there's no rush. Maybe someone can weigh in about that.
> > 
> > Otherwise it would remain as a source of instability for many years, and conscientious devs would have to insert a check for Emacs 30 that reminds the user that the package may be terribly outdated.
> > 
> > At least one other developer agrees the current setting is "fragile" (https://github.com/melpa/melpa/pull/9133#issuecomment-2351653325).
> 
> I've read this thread, and I must confess that I'm not convinced.
> Besides being waaay too late for such changes in Emacs 30, I also
> don't think we have enough experience at this time to make such
> decisions.  Both package-vc and use-package are relatively very new in
> Emacs, and we have yet to collect enough user experience and
> understanding of what are the expectations and how they should work
> together.  Moreover, use-package-vc-prefer-newest is a new option in
> Emacs 30, and we rarely make new optional behaviors take effect by
> default as soon as they are introduced, to avoid behavior changes
> which will surprise and perhaps annoy.  We made it an option to make
> it easily adaptable to user preferences and needs.
> 
> Some of the rationale (like outdated Package-Version) also sounds like
> it isn't our problem to solve.  It should be easy for the respective
> package developers to get their act together in this matter.  It is
> also TRT for them.  When a user uses use-package, he/she doesn't
> necessarily want the latest commit, so the change isn't as obvious as
> you make it sound, IMO.
> 
> 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?)

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.

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.

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.

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.