From: Tom Gillespie <tgbugs@gmail.com>
To: Tim Cross <theophilusx@gmail.com>
Cc: emacs-orgmode@gnu.org
Subject: Re: [PATCH] Delete some Emacs 24 compat code
Date: Tue, 9 Aug 2022 21:55:23 -0700 [thread overview]
Message-ID: <CA+G3_PNh7d1Ms85Bb7mZhkPsGdBGu1+_kFncRd6UkXZoVt6Xjw@mail.gmail.com> (raw)
In-Reply-To: <864jykhnl4.fsf@gmail.com>
> 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.
The weasel words here are "proper operation" because it covers everything
from "will byte compile without errors (but maybe with warnings)" to "has
zero bugs and will never fail under any circumstances." My interpretation
is that Package-Requires means "will byte compile without errors" because
all software has bugs. Unfortunately package metadata doesn't seem to
have another field for something like Package-Supported-Version.
> 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.
I agree that this is an issue. I think the easiest solution would be to add
something to org-submit-bug-report which would inform the user that they
are running a version of org that is too new for their version of emacs and
is thus unsupported.
Another solution would be for package metadata to deconflate "will
immediately fail if you try to run this on old versions" from "only make
this update available to users running emacs at or above this version."
I think this is a variant of your suggestion to make upgrading to unsupported
versions more difficult but not impossible.
> 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).
I don't see how a bug that is only encountered on 25 is different from
any other bug in this case. We aren't going to continue to support
25 by continuing to maintain a 9.5.x branch when we go on to 9.6,
but as long as we don't e.g. start using e.g. functions that are not
present in 25 that cause immediate runtime failures or byte compile
failures, then hard blocking users on 25 from installing from elpa at
all seems like artificially depriving users of the ability to choose at
their own risk (albeit to make the maintainer's lives easier).
> 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.
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.
Best!
Tom
next prev parent reply other threads:[~2022-08-10 4:56 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
2022-08-10 4:55 ` Tom Gillespie [this message]
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=CA+G3_PNh7d1Ms85Bb7mZhkPsGdBGu1+_kFncRd6UkXZoVt6Xjw@mail.gmail.com \
--to=tgbugs@gmail.com \
--cc=emacs-orgmode@gnu.org \
--cc=theophilusx@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).