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

["Martin Edström" <meedstrom@runbox.eu>]

On Mon, 16 Sep 2024 20:57:15 +0300, Eli Zaretskii <eliz@gnu.org> wrote:

> > [1] https://github.com/slotThe/vc-use-package
> 
> That's a different package, so I don't see why we should necessarily
> follow its decisions.  When users migrate to use-package :vc, they
> should expect some changes in the default behavior.
> 
> > You cannot rely on users to configure this kind of thing for themselves, most of them would not know the reason why things broke. It is not a matter of "liking" the default, since breakage in one direction would be much more severe than is possible to encounter in the other direction (years out of date vs. slightly too new).
> 
> Nowadays an Internet search will bring the answers very quickly and
> efficiently.  And if that's not enough, there are enough user-level
> help forums where people could ask questions and get useful answers.
> 
> IOW, "not a catastrophe".
> 
> > It is absolutely Emacs' responsibility, at least as long as stability for users is desired. Isn't it the reason to favor conservative defaults? Avoiding breakage? I get this new default comes from a good place, intending stability, but it is a radical departure from what has been the norm established by Straight/Quelpa/el-get and their use-package integrations, and that will work against stability.  
> 
> We can only be responsible for stability when our own implementation
> and decisions are concerned.  We cannot be expected to blindly follow
> someone else's decision in the name of "stability" for users who
> switch from other packages, this kind of expectation is completely
> unreasonable.

I am sorry.  I use the word "responsibility" perhaps different from many people, I think of responsibility as basically good, a nice thing to have, but as words go it's a powder-keg with different interpretations. I did not mean to be entitled nor expect the Emacs volunteers to do any services for me or anyone else.

I also have not contributed any core Emacs code (yet), and I am very grateful to those who have, such as yourself, Eli.

We are currently enjoying a Golden Age of Emacs, and I see that as being a lot about the Emacs Lisp ecosystem wrapped around the Emacs core, and of course, Emacs core doing what it can to be friendly to that ecosystem.  To me, Emacs *is* the ecosystem.

That frames my opinions about this new default setting.  It does not seem to me like the theoretical benefits outweigh the costs to GNU reputation each time a GitHub issue is raised to a developer who preferred to just do rolling releases (e.g. just today I had to warn someone at https://github.com/JuliaEditorSupport/julia-emacs/issues/212).

I believe I've said all I had to say, but to be very clear for the record, I consider this default to be radical, not conservative, at least from the perspective of causing least breakage.  I also do not think it is good stewardship of the ecosystem to say that each user can just Google the solution once they face breakage.  It affects developers too, who may not have learned about this default, and lose users as a consequence.

Anyhoo. The concept of versioned releases is good, and if git/hg tags are checked, that's great. Maybe it's not the end of the world that devs who want pure "rolling releases" are forced to adopt some sort of automated toolchain that pretends to cut releases for every commit, or insert a warning message to their users to upgrade to the master branch. But novice devs and experimental packages frequently fit into this box so I have mixed feelings about that.