From: Tim Cross <theophilusx@gmail.com>
To: Bastien <bzg@gnu.org>
Cc: Ihor Radchenko <yantar92@gmail.com>,
Samuel Wales <samologist@gmail.com>,
Max Nikulin <manikulin@gmail.com>,
emacs-orgmode@gnu.org
Subject: Re: [PATCH] Delete some Emacs 24 compat code
Date: Tue, 09 Aug 2022 08:12:29 +1000 [thread overview]
Message-ID: <86czdawew8.fsf@gmail.com> (raw)
In-Reply-To: <87pmhad9gv.fsf@gnu.org>
Hi Bastien,
all you wrote is fine IMO. However, I think Ihor's point was mainly in
response to the request that we notify the list when compatibility is
going to be lost and that when it comes to versions less than the
currently maintained versions, this isn't really possible.
To put it in more concrete terms, based on your example below, we don't
know exactly when org loses compatibility with Emacs 25.x because we are
no longer testing against that version (we are only testing against 28,
27 and 26). We don't know the precise commit which breaks compatibility
with 25 as we are no longer testing against that version, so cannot
notify the list when compatibility is lost.
Obviously, when we do know, we can notify the list. Sometimes, it is
clear that a patch or commit will break compatibility with an old
version. However, we cannot provide any guarantee we will always notify
the list when that compatibility is lost. Often, this only becomes known
when someone posts to the list to say it no longer works.
Therefore, I think the position should be that once an emacs version is
no longer one of the supported versions (current stable Emacs release
plus two previous major versions), there is no guarantee we will inform
the list when compatibility is lost. If you are running an unsupported
versions, either you should avoid updates or be prepared for breakage
without warning. When we do know a commit has broken compatibility, that
information will be relayed to the list, but we cannot guarantee we can
provide such information at the time the change is committed. Running an
unsupported versions is at your own risk.
Bastien <bzg@gnu.org> writes:
> Hi Ihor,
>
> Ihor Radchenko <yantar92@gmail.com> writes:
>
>> Could you please elaborate on how exactly we can determine if a
>> commit changes the compatibility status?
>
> Today, we are interested in knowing whether Org is compatible with
> Emacs 28.1, Emacs 27.1 and Emacs Emacs 26.1.
>
> Ideally, this means maintainers run the test suite against these
> versions in order to check that bugfixes and/or new features don't
> introduce incompatible code.
>
> We don't need to run tests against Emacs <=25: if Org runs okay on
> Emacs <=25, it's good. If not, users can report it: maintainers are
> not bound to fix such incompatibilities and we don't need to know or
> to announce them beforehand since we don't make a promise that Org
> will run with Emacs <=25.
>
> On https://orgmode.org/worg/org-maintenance.html I added this:
>
> It does not mean that Org will not be usable, at least partially,
> with older Emacsen: but maintainers are not bound to fix bugs
> reported on them.
>
> WDYT?
next prev parent reply other threads:[~2022-08-08 22:27 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 [this message]
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
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=86czdawew8.fsf@gmail.com \
--to=theophilusx@gmail.com \
--cc=bzg@gnu.org \
--cc=emacs-orgmode@gnu.org \
--cc=manikulin@gmail.com \
--cc=samologist@gmail.com \
--cc=yantar92@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).