search

nix-community / emacs-overlay

Bleeding edge emacs overlay [maintainer=@adisbladis]
510 stars 168 forks source link

[Feature Request]: Provide an attribute to track the `emacs-30` branch #420

Closed panchoh closed 2 months ago

panchoh commented 3 months ago

emacs-next and variants (emacs-next-pgtk, etc.) tracking the emacs-30 release branch would allow wannabe testers of the upcoming Emacs 30 release easy access to up-to-date builds, thus increasing the odds of discovering and reporting bugs on it, for the benefit of the Emacs community.

Note that Emacs 30.0.90 has been recently reached, hinting that the release is not too far ahead.

Maintenance-wise, the emacs-next attributes could either be dropped in the interphase, or maybe be turned into aliases of emacs-git. By interphase I mean the periods in the year where the release branch for the next major Emacs version has not yet been cut from master.

adisbladis commented 3 months ago

I've always wanted this overlay to be as close to zero maintenance overhead as possible. I don't like the idea of adding anything that we know is going to require future periodic maintenance.

panchoh commented 2 months ago

I've always wanted this overlay to be as close to zero maintenance overhead as possible. I don't like the idea of adding anything that we know is going to require future periodic maintenance.

I see your point.

I just came across this issue on Steve Purcell’s nix-emacs-ci, where he expressed similar concerns.

There, they took the approach of defining emacs-release-snapshot, which they point to, say github:emacs-mirror/emacs?ref=emacs-30, but they don't track HEAD but a particular tag, such as 30.0.90, that is a moving target and have to keep bumping from time to time. This is a burden.

So, if instead we were to track HEAD on the release branch (analogous as with emacs-master), only one bump will be required per year, that is, emacs-next and friends would track the emacs-30 branch until emacs-31 is cut. This change could even be brought in by bot, by periodically checking for branches on the Emacs repo, but even without that, I'd say that the burden is minimal.

Thougths?

panchoh commented 2 months ago

So 94f05bf3834c7929b512753dc73602a6df770cf8 happened, which esentially renders this argument moot.

This design is really low maintenance, kudos for that. TIL.