Tom Gillespie <tgb...@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). .