From: Tim Cross <theophilusx@gmail.com>
To: Samuel Wales <samologist@gmail.com>
Cc: Tom Gillespie <tgbugs@gmail.com>, emacs-orgmode@gnu.org
Subject: Re: [PATCH] Delete some Emacs 24 compat code
Date: Thu, 11 Aug 2022 15:56:05 +1000 [thread overview]
Message-ID: <86a68bqpd4.fsf@gmail.com> (raw)
In-Reply-To: <CAJcAo8t0yHOCofe5KtqmcnA2GQp-op5JiLogM982N+SiK=Fe_A@mail.gmail.com>
Samuel Wales <samologist@gmail.com> writes:
> tim cross, i would like to ask politely for you personally to
> henceforth please be VERY VERY careful when you say that i said or
> wanted something or tried to do something. i am not referring to this
> thread but general espeially in another thread.
BTW, just for the record, what I was referring to were the two posts
where you wrote
> idk about others, but as a luddite follower of bugfix/maint, if
> poissible and not too annoying to do, i would be interested in
> knowing, at the email subject header level, that the upcoming
> bugfix/maint release [state org version number] will not support <=
> [state emacs version number] so that i can prepare at my glacial
> luddite pace. this is probably already done, but making it prominent
> beforehand might help signal the need for changes with lots of time or
> simplify git stuff [e.g. pull soon as the last pull and make a note
> not to pull after that, which prevents the need for figuring out
> rebasing again].
and in particular
> i use git version, not elpa, so for me, mailing list could tip me off
> as early as possible, but not too early, if it said in email subject
> header line that in a known upcoming release, it has been decided that
> a specified emacs version will no longer be supported [note: i presume
> and hope this would not occur in just a plain git update for such a
> thing but would get a release that gets noted in email and get that
> advance notice],
> then upon seeig such email i can stop pulling from git until i am able
> to upgrade emacs. [lots of stuff takes lots and lots of time for me
> in my case] idk if practical, but just saying what seems like it
> would be useful to me.
> i would then stay at something reasonably close to the first release
> that does not support that version fo emacs.
and the only point I wanted to make is that this isn't practical because
we don't always know when a patch removes compatibility for a
non-supported version of Emacs (i.e. major version four or more versions
behind current major version).
The other point to note is that git commits are not releases and
commits happen before releases. So, while an org release does specify
precisely which Emacs versions are supported, commits occur in-between
releases. Supported versions don't change during those commits, but
support for older unsupported versions of emacs could be lost at any
commit and as we don't test against those older versions, we won't know
until someone reports it later.
At the end of the day, if your running org in an Emacs version which is
four or more major versions behind the current stable release, you are
at risk of breakage at any update and this is likely to happen without
notice (if you update often, you are likely to be the first person to
discover the loss of compatibility).
Good news is, as your running from git, it is trivial to revert back to
an earlier version. Something which ELPA users cannot do.
prev parent reply other threads:[~2022-08-11 6:15 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
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 [this message]
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=86a68bqpd4.fsf@gmail.com \
--to=theophilusx@gmail.com \
--cc=emacs-orgmode@gnu.org \
--cc=samologist@gmail.com \
--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).