search

cmacrae / emacs

Nightly custom Emacs builds for macOS Nix environments
MIT License
40 stars 17 forks source link

version 28 does not match emacs HEAD new version of 29 #2

Closed montchr closed 2 years ago

montchr commented 2 years ago

Since a recent commit, the GitHub Actions workflow has been building binaries for version 29.0.50 but they're stored in a store path indicating the expected version is 28.

https://github.com/emacs-mirror/emacs/blob/0f2df365592636aaa6bcd72fc662774eb35c69d1/README#L5 https://github.com/cmacrae/emacs/runs/3785293195?check_suite_focus=true#step:8:748

montchr commented 2 years ago

Related question: should this repo continue providing binaries for emacs 28 in addition to the new emacs 29?

This change came as a surprise, so I've pinned my version to 8bbbdae607d3f03a8e6c488b310d9443f6ff11bf

cmacrae commented 2 years ago

Hey @montchr 👋 Thanks for raising this. Personally I'd like to put together some simple logic to work out the version and set that dynamically, so it doesn't have to be maintained.

This change came as a surprise, so I've pinned my version to 8bbbdae

Perhaps there's something I could work out with a branch workflow to provide version streams :)

cmacrae commented 2 years ago

I've taken an initial stab at updating the package version dynamically. A couple kinks to work out, but it's a good start, I think :)

montchr commented 2 years ago

Thanks @cmacrae! Looks like your version update addresses the issue here, so I'll close.

I'd still like to build from the emacs-28 release branch, since there's still some commit activity there, including a fix for a bug involving xref which might be giving me some trouble locally. emacs-overlay doesn't seem to easily accommodate tracking the emacs-28 branch either, so I've forked your repo to pin the release branch and build binaries in my cache for the time being.