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