emacs-orgmode@gnu.org archives
 help / color / mirror / code / Atom feed
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: Wed, 10 Aug 2022 11:13:12 +1000	[thread overview]
Message-ID: <864jykhnl4.fsf@gmail.com> (raw)
In-Reply-To: <CA+G3_PPo6CkEewUbpqi-suR5LpPi8hzKB8YKXMADaUe1EAnd0w@mail.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.


  reply	other threads:[~2022-08-10  1:53 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 [this message]
2022-08-10  4:55                     ` Tom Gillespie
2022-08-10 14:18                       ` Tim Cross
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=864jykhnl4.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).