Re: [PATCH] Delete some Emacs 24 compat code

[Samuel Wales <samologist@gmail.com>]

your opinion is noted.  mine remains, but maintainers are welcome to
do as they think is right.  i stated what i thoguht might be useful
for my ase.  no further discussion needed.

On 6/30/22, Tim Cross <theophilusx@gmail.com> wrote:
>
> Samuel Wales <samologist@gmail.com> writes:
>
>> 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.
>>
> While what your asking for may sound reasonable, I don't think it is
> practical. There is no sudden decision to stop supporting a version in
> the sense that suddenly, at that point, the version is no longer
> supported. We really only know that a past version is no longer
> supported when it stops working and is more than 2 releases behind the
> current Emacs version (any less and it is a bug which will get fixed).
>
> The supported version policy has already been communicated on this
> list. That policy will not change without notice, so you know exactly
> what is supported at all times.
>
> There is no precise point where we can send out a message saying a
> version is no longer supported. Best that can be done is say that any
> Emacs version older than two releases behind the current stable release
> is no longer supported. That doesn't mean it won't work, it just means
> if there are problems, they won't be fixed and there should be no
> expectation it will work if your running an unsupported Emacs version.
>
> Thing is, no testing is done against older versions, so it isn't always
> clear precisely when org stops working with an older unsupported
> version.
>
> Current stable version is 28. Therefore, if your running Emacs 25 or
> earlier, you *should not* pull updates from git as they may not be
> compatible with your Emacs version. When Emacs 29 is released, stop
> pulling from git if your running Emacs <= version 26.
>
> Of course, none of this is a big issue as you do build from git. Should
> you find your most recent pull is no longer compatible with the version
> of Emacs your running, it is trivial to revert to the version you were
> running before - you just need to do a checkout for the earlier
> revision and rebuild. As pointed out elsewhere in this thread,
> package.el has minimum version spec, so this isn't an issue for
> package.el users.
>
>


-- 
The Kafka Pandemic

A blog about science, health, human rights, and misopathy:
https://thekafkapandemic.blogspot.com