bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#62720: 29.0.60; Not easy at all to upgrade :core packages like Eglot


From: Dmitry Gutov
Subject: bug#62720: 29.0.60; Not easy at all to upgrade :core packages like Eglot
Date: Wed, 19 Apr 2023 18:48:00 +0300
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.10.0

On 19/04/2023 15:05, Eli Zaretskii wrote:
It isn't my call in this case, but FWIW: I still have no idea why
wouldn't we want Eglot 1.14 or 1.15 to be in Emacs 29.1.  I didn't
hear any serious argument against doing that; every reason that was
raised was almost immediately explained away as not being a hard
limitation.

Okay, let me try to answer this: since the goal is (apparently) to have a stable version of Eglot in emacs-29, we don't know yet whether 1.14 or 1.15 is "stable".

And mind you: Emacs 29.1 will not be released tomorrow or the day
after.  We still have at least several weeks till then, with at least
one more pretest.  So the decision whether to import a newer Eglot
into the release branch doesn't have to be today.  However, the
argument against updating Eglot on the release branch, such as they
were, are of some vaguely "fundamental" nature, so I'm not sure a few
more weeks of time will change the decision.  No one said something
like "if Emacs 29.1 were to be released in NN weeks or more, it would
be okay to update Eglot on the release branch."  But then I already
admitted to not understanding those reasons, so maybe I'm missing
something here.

Let's imagine I was making this choice.

I would include (or propose for inclusion) Eglot 1.x.y in Emacs 29 only N weeks after it has been tagged on master and thus published to ELPA, on the condition that no major bugs have been discovered in the meantime that required major reworks (because any bugfix would reset the timer to L weeks where L < N, but a major change would reset it to N weeks again). That would be the general guideline. Add to that the maintainer's best judgment, who would be able to reduce or extend these periods on case by case basis as well, according to the changes that went into every release.

To answer the original question: N weeks still haven't passed (I guess) since 1.15 was tagged, so we don't quite know whether it's acceptable for emacs-29.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]