GNU bug report logs -
#62720
29.0.60; Not easy at all to upgrade :core packages like Eglot
Previous Next
Reported by: João Távora <joaotavora <at> gmail.com>
Date: Fri, 7 Apr 2023 22:11:01 UTC
Severity: normal
Found in version 29.0.60
Done: Eli Zaretskii <eliz <at> gnu.org>
Bug is archived. No further changes may be made.
Full log
Message #559 received at 62720 <at> debbugs.gnu.org (full text, mbox):
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.
This bug report was last modified 2 years and 17 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.