With Steve's blessing, I vote we drop support for 23, since that will give us some decent improvements.

from s.el.

I think it's 100% fine to not support Emacs 23. I think at this stage you could also reasonably drop Emacs 24, to be honest, if it causes any extra maintainer overhead here. The last 24.x release was 2015-04-10, almost 7.5 years ago.

from s.el.

@magnars - should consider when updating Travis/CI.

from s.el.

s.el is a library that is being used by lots of packages and lots of people, so I am wary of dropping support of older Emacsen. However, maybe Emacs 23 is old enough to warrant it regardless. I would be interested to hear if @purcell has any input on this.

from s.el.

@purcell - Hi Steve, any thoughts?

from s.el.

Related to backwards compatibility / testing capability for the package to robustly support older Emacs versions. We have access to 24.x and up via Steve's purcell/[email protected].

There's a couple of caveats specific to GitHub actions as CI.

• 24.x fails to pass tests on GH Actions

• 26.x fails to pass tests on GH Actions

However on a local run the tests pass on 26.3 as illustrated below:

Potentially this can be mitigated using a different CI, or using Docker containers instead of the standard GH Action internal runners.

The other question...

Do we really need to support Emacs prior to 27.1? I have no data on usage of legacy versions. Does anyone?

from s.el.

FWIW we get one failing example on Emacs 24.1 (run locally.)

from s.el.

Resolved as dropping Emacs 23.x support.

from s.el.