|
From: | Dmitry Gutov |
Subject: | bug#46610: Interactive mode tagging for python.el navigation functions |
Date: | Thu, 18 Feb 2021 21:57:56 +0200 |
User-agent: | Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 |
On 18.02.2021 21:47, Eli Zaretskii wrote:
Cc: ddavis@ddavis.io, larsi@gnus.org, 46610@debbugs.gnu.org, monnier@iro.umontreal.ca From: Dmitry Gutov <dgutov@yandex.ru> Date: Thu, 18 Feb 2021 19:54:06 +0200My question is more of the conceptual kind, not necessarily about this specific change. Your original response was also about the principle, AFAIU.I guess I'm not sure what you are asking about at this pointLet me repeat my original question:
Very good.
So packages on ELPA are allowed to be ahead of those in core, but not vice versa? Is that really the intent that we allow them to diverge, but only in one direction?yes, python.el is allowed to incorporate support for some new features from Emacs 28, as long as they are backward-compatible, or gated behind a version check.If python.el in emacs.git is allowed to be different from that in elpa.git (and AFAIU we already allow that), then there should be no need for any compatibility shims in the version that is in emacs.git.
Then this part of my first reply should be most pertinent: Then we (someone? who?) either have to maintain both versions Emphasis on "who".
[Prev in Thread] | Current Thread | [Next in Thread] |