From: Tim Cross <theophilusx@gmail.com>
To: Tom Gillespie <tgbugs@gmail.com>
Cc: emacs-orgmode@gnu.org
Subject: Re: [PATCH] Delete some Emacs 24 compat code
Date: Thu, 11 Aug 2022 00:18:56 +1000 [thread overview]
Message-ID: <86iln0qh35.fsf@gmail.com> (raw)
In-Reply-To: <CA+G3_PNh7d1Ms85Bb7mZhkPsGdBGu1+_kFncRd6UkXZoVt6Xjw@mail.gmail.com>
Tom Gillespie <tgbugs@gmail.com> writes:
>
> As mentioned above, I also like this approach. We could create a hack
> to work around the missing package metadata field, which would cause
> a failure when trying to build on emacs < 26 unless org-i-know-what-i-am-doing
> or some such is non-nil. The error message would say something along
> the lines of "this version of org {org-version} will run on {emacs-version}"
> but it is not supported. If you still want to install it, please run
> (setq org-i-know-what-i-am-doing t) and then install the package again"
> or something like that.
>
What I don't like with this approach is that I think it is making
everything far too complicated. The other issue at the core of this is
that we don't always know if it actually does run on an unsupported
version as no testing is done against those earlier versions. We would
have to have a message like "It may or may not work on this unsupported
version of emacs, run at your own risk."
Personally, I would just keep it far simpler. Anyone running a version
of Emacs which is 4 major versions behind the current stable release
should expect problems and challewnges if they also want to run the
latest versions of packages under a version that old . When that out of
datge, I think it is reasonable to expect that if you want to install
the latest version, you will need to do it manually and not via
package.el.
I don't think we have the resources for anything more complicated. We
state what versions it is supported on and leave it at that. When we say
supported, we can extgend that to mean able to be installed via
package.el.
Recall where all this started. Samuel wanted to be able to run Org on a
unsupported version of Emacs and for there to be a message or some sort
of alert once org no longer runs under that version of
Emacs. Unfortunately, with a package a large and complex as org,
defining what no longer runs means is difficult because that will
largely depend on which features you rely on. The other problem is we
don't test against unsupported versions, so we only know when a
feature/facility no longer works once someone reports it. Even then, it
may not be straight-forward as the feature/function may only be broken
in some configuration scenarios.
I do like the idea of having the bug reporting functionality check
whether the version being used is a supported version and alerting the
user when it isn't. Otherwise, I think keep it very simple. Make it
clear what is supported and only enable it to be installedl via
package.el on versions of Emacs which are in the supported version
list. Anyone outside that list can either stick with the version they
have installed (no updates), manually install and run the risk or plan
to update Emacs to a supported version.
At the end of the day, we are not forcing anyone to upgrade. They can
continue to use the version they have running under Emacs 25 for as long
as they want. Obviously, it won't get bug fixes etc, but that is what
unsupported means. I suspect most people would rather have package.el
tell them that their Emacs version is not supported than have it
silently do the update and then find some feature they rely on no longer
works (especially as downgrading a package to an earlier versions isn't
something package.el supports). .
next prev parent reply other threads:[~2022-08-10 15:02 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-06-30 11:19 [PATCH] Delete some Emacs 24 compat code Stefan Kangas
2022-06-30 13:36 ` Ihor Radchenko
2022-06-30 13:39 ` Ihor Radchenko
2022-06-30 15:25 ` Stefan Kangas
2022-07-02 4:11 ` Ihor Radchenko
2022-06-30 15:25 ` Max Nikulin
2022-06-30 15:47 ` Ihor Radchenko
2022-06-30 22:46 ` Samuel Wales
2022-07-01 2:45 ` Ihor Radchenko
2022-07-01 3:11 ` Samuel Wales
2022-07-01 4:00 ` Tim Cross
2022-07-01 4:44 ` Samuel Wales
2022-07-17 9:35 ` Bastien Guerry
2022-07-18 1:23 ` Samuel Wales
2022-07-31 12:54 ` Ihor Radchenko
2022-08-08 15:46 ` Bastien
2022-08-08 22:12 ` Tim Cross
2022-08-09 0:41 ` Bastien
2022-08-10 11:50 ` Ihor Radchenko
2022-08-11 10:23 ` Bastien
2022-08-11 11:53 ` Ihor Radchenko
2022-08-12 6:30 ` Bastien
2022-08-09 15:58 ` Max Nikulin
2022-08-10 0:06 ` Tim Cross
2022-08-10 0:59 ` Tom Gillespie
2022-08-10 1:13 ` Tim Cross
2022-08-10 4:55 ` Tom Gillespie
2022-08-10 14:18 ` Tim Cross [this message]
2022-08-11 2:59 ` Samuel Wales
2022-08-11 5:34 ` Tim Cross
2022-08-11 5:56 ` Tim Cross
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.orgmode.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=86iln0qh35.fsf@gmail.com \
--to=theophilusx@gmail.com \
--cc=emacs-orgmode@gnu.org \
--cc=tgbugs@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).