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.