Re: [PATCH] Delete some Emacs 24 compat code

[Tim Cross <theophilusx@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). .