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 <theophil...@gmail.com> wrote: > > Samuel Wales <samolog...@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