Re: [PATCH] Delete some Emacs 24 compat code

[Tim Cross <theophilusx@gmail.com>]

Tom Gillespie <tgbugs@gmail.com> writes:

>> Please, keep ";; Package-Requires: " version in org.el consistent with
>> such statement (Should it be updated for the bugfix branch as well?).
>
> Unfortunately it is not clear that this is the right thing to do because
> nearly every feature of org may work on old versions. Should we put
> users through the pain of having to fight the metadata saying that they
> can't run org on an old version of emacs when only a tiny subfeature
> may or may not be broken? For example, I can load the current
> version of org and go through most of my normal workflows without
> issue on 25.
>
> Package-Requires does not mean what it says, what it actually means
> is "actively does not work on any versions not specified" which is not
> true if we were to say >=26 and would make users' of older versions
> of emacs lives harder. What this means is that we could say >=25
> (which is what org.el current has by listing 25.1) because it is possible
> to load current versions of org-mode on 25 but not on 24 (which works
> only at 9.4.6 at 652430128896e690dc6ef2a83891a1209094b3da).

The manual actually says

  "If this exists, it names packages on which the current package
  depends for proper operation."

so I think it is reasonable to only list the minimum supported Emacs
version, not the minimum version where it partially or fully works, but
is not supported.

Problem I see with your approach is there will be an expectation that if
it lists Emacs 25.x that it works under that version and anything which
doesn't work is a bug. People will not check this list, README or NEWS
files to verify what version of Emacs is compatible with - if they can
use package.el to install it, they will expect that it works without any
issues and any encountered are either a configuration error or a bug.

Even worse, once a problem with (for example) Emacs 25.x is found, what
do we do? Would we have to push out a new version just to now update the
requires line and forcing an update for all users? Which commit do we
use to push out that update (given there will have been changes since
the last release and we may not be ready to push them out in a new
version yet). 

An alternative approach is to deliberately make it harder to upgrade org
if your running an unsupported version of Emacs. This would prevent
automatic updates to a version which is not supported and (possibly) doe
sot work, either partially or fully.  Manage user expectations by making
it very explicit to the end user they are running a older version of
emacs which may not be compatible with latest version of org.They can
either decide to continue with the existing version they have installed
or they can upgrade to a more recent Emacs or they can install org
manually if they really want to accept the risk and run in an
unsupported configuration.