Re: [PATCH] Delete some Emacs 24 compat code

[Tim Cross]

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.