Related -- how many versions of Emacs should be supported in this repo? When 31 is added, should the oldest one be dropped?

I very much second that. I mean, it's great to have older versions under certain circumstances, but I don't think that @d12frosted should have to maintain all of them forever.

Related -- how many versions of Emacs should be supported in this repo? When 31 is added, should the oldest one be dropped?

A good question. I don't mind formulas staying here, but I pretty much want to kill CI workflows. I think it makes sense to care only bout current release, next release candidate if available and master. So normally we are talking about two versions and during transition/release of new version (like now) there are three versions.

I mean, it's great to have older versions under certain circumstances, but I don't think that @d12frosted should have to maintain all of them forever.

❤️ I appreciate what you say. Frankly, the most 'complicated' features from maintainer point of view are not related to Emacs version per se, but rather to (a) native compilation and (b) environment of the builds.

#695

WDYT?

I think that my general concern with that approach is that it seems to send a mixed message. If it's not under CI, is it really maintained? If anything is wrong (like after a new version of macOS is released), would you or someone fix it? How many people are relying on the older versions? Could they get them from somewhere else like https://emacsformacosx.com/builds instead?

Personally, I'd be inclined to only maintain the most recent version and development versions and include a link to https://emacsformacosx.com/builds in the README. Maintaining OSS is enough work 😄