MacVim r180.1 (prerelease)

[ychin]

Updated to Vim 9.1.1000

This is a pre-release version of MacVim. To use the latest stable release, see https://github.com/macvim-dev/macvim/releases/latest

What's Changed

What's Changed

• Use getregion() for showing definition of selected texts by @ychin in Use getregion() for showing definition of selected texts #1508
• Expose setting to only open untitled window only on reactivation by @ychin in Expose setting to only open untitled window only on reactivation #1509
• Add setting for whether to show document icon at title bar by @ychin in Add setting for whether to show document icon at title bar #1510
• Dark mode improve docs for v:os_appearance and add tests by @ychin in Dark mode improve docs for v:os_appearance and add tests #1511
• Add support for macos-15 for CI by @ychin in Add support for macos-15 for CI #1514
• Fix non-native fullscreen quit to black screen bug by @ychin in Fix non-native fullscreen quit to black screen bug #1516
• Fix resizing MacVim window occasionally result in a stale wrong Vim size by @ychin in Fix resizing MacVim window occasionally result in a stale wrong Vim size #1518
• Fix non-native full screen misc crash, background color, and transparency issues by @ychin in Fix non-native full screen misc crash, background color, and transparency issues #1521
• Fix menu item "MacVim Website" to go to correct URL by @ychin in Fix menu item "MacVim Website" to go to correct URL #1524
• Fix full screen window restore / multi-screen / misc issues by @ychin in Fix full screen window restore / multi-screen / misc issues #1525
• New defaults: Smoothly resize window, guioptions+=k by @ychin in New defaults: Smoothly resize window, guioptions+=k #1528

New Contributors

• @ilyagr made their first contribution in README: link to build instructions, slight polish to Markdown #1520

Full Changelog: release-180...prerelease-180.1

---

This discussion was created from the release MacVim r180.1 (prerelease).

[pbnj]

Hello @ychin , thank you for your work on macvim.

Does MacVim follow a release schedule?

If there is no release schedule, is it possible to automate/schedule a new MacVim release every 50-100 vim releases?

I am asking because the last MacVim release was 180 on 2024-09-11 (Vim version 9.1.0727).

A lot of enhancements and bug fixes have landed in upstream Vim during that time (current Vim version is 9.1.1039).

MacVim users have to wait for a new release of MacVim to receive latest Vim enhancements/fixes.

[ychin]

Personally I would want to make a release more often. I was hoping for maybe a new release every <2 months but obviously that has not quite worked out to be the case so far.

I can probably commit to doing pre-release releases more often and do one at least once per 1-2 months. If I don't do that please file an issue. These are still stable and provides the most up-to-date Vim and if you want up-to-date Vim you should use the pre-release channel (like this recent release).

For full releases I tend to be more careful and look through things, make sure the release notes are correct, and also test MacVim in older macOS versions in VMs manually etc to make sure they work so it would naturally be more time consuming. I also like to make sure Vim is in a good shape when I do full releases which could involve some vibe check since Vim kind of has a rolling release schedule and not fixed point releases (unless you count the big ones like 8.1, 8.2, etc). That's why it's hard to guarantee a fixed schedule. The current release rate is still too slow for my liking though.

For full releases we also lost the ability to build legacy builds (since GitHub CI removed the macos-12 runner) so I'm in the process of getting a local VM to build that in the time being.

If there is no release schedule, is it possible to automate/schedule a new MacVim release every 50-100 vim releases?

One reason this (basing on Vim releases) may not make that much sense is that as a downstream fork, MacVim needs to merge from upstream to get those changes, and this is not an automatic procedure. It requires a manual effort and sometimes it is a simple git merge vim/master && git commit command that takes 1 -2 minutes, sometimes it's a multi-hour debugging session because of some oddity with what happened Vim upstream or how we are using a new macOS or Ruby version or something. It's always a different issue every time and sometimes the upstream merge reveals some bugs with Vim itself etc so I don't have a simple answer what the root cause for the upstream merge challenges is. I think it's better to just commit to a time-based schedule like "a new release every 1/2 months". It's also better for the user as that's an easier expectation to follow than basing that on Vim version number.

Another reason for not doing automatic releases is I strongly prefer having a human in the loop in the release process for sanity checking. Also, currently the signing keys are not uploaded to GitHub CI (and I will likely never set it up that way) so I at least need to manually sign/notarize it. The process isn't that involved though so I should be able to do it every 1-2 months.

A lot of enhancements and bug fixes have landed in upstream Vim during that time (current Vim version is 9.1.1039).

Just curious was there any specific changes you were looking for?

---

tldr: Ideally a release at least every 1-2 months. I can try to make sure that's the case and file an issue if it's not.

[pbnj]

That seems reasonable.

Thank you for explaining your thought process and the complexity around releases.

I agree with needing a human in the release process loop for sanity checks. Do you think that having an automated nightly build with latest Vim would help the release process overall while maintaining your stated goals and preferences?

For example:

• If a nightly build does git checkout nightly && git pull upstream master && git merge vim/master && git commit && git push origin nightly and it completes successfully (i.e. no merge conflicts), then a human (e.g. you, or anyone from the MacVim community that wants to help test/flush out bugs) could then download the nightly build and test it. Once you determine that nightly build passes sanity checks, you could promote that as a pre-release (again, potentially encouraging early users to report bugs early). Then, when you're ready, release it as a new version.
• If a nightly build fails the git checkout nightly && git pull upstream master && git merge vim/master && git commit && git push origin nightly step, then you're proactively alerted that this could be a multi-hour debugging session.

Just curious was there any specific changes you were looking for?

Nothing in particular. There were a bunch of security/bug fixes, a few new built-in plugins, and a few new filetypes that I rely on.

[ychin]

I think from having done a lot of these merges, I think the failure rate of these auto-merges would just be too high for it to be worth it. Often times there will be minor merge conflicts that are trivial to fix, but still requires a bit of work. It's possible to invest in scripts to automate that but it's more effort that's needed to be done (see https://github.com/macvim-dev/macvim/wiki/Merging-from-upstream-Vim). Also, nightly builds won't be code signed and it will make it difficult to integrate into the existing Sparkle update ecosystem, meaning that anyone interested in it would have to grab it manually, download it, strip the quarantine flag (which is how you can tell macOS to run unsigned / non-notarized apps), etc. I'm not sure if there's enough value in it to invest in such efforts.

But I do hear you on the issue of a slow release cadence. What I can do is:

1. make sure I merge from upstream more often (often times these merge conflicts accumulate so doing infrequent merges doesn't really save me time in the long run). I used to merge every 1-2 weeks and somehow got slower over the years. I usually like to scan through the upstream commits to see if there are breaking changes but I don't think that should block an upstream merge as I can do this work later.
2. publish official release or pre-release signed release builds every 1-2 months as I said.
3. I can also make it so that we always build a DMG installer from CI so every time something gets merged in the master branch it will generate a DMG and a dedicated user can download it and try it out (it will be unsigned though). Right now, we don't generate a DMG installer unless we are doing a release, but there's no good reason for that (it saves a measly 10 seconds).

Does that sound good? Just from experience I think adding a nightly upstream merge would end up costing more time dealing with GitHub CI than saving work.

[pbnj]

Does that sound good?

Yes.

Again, thank you very much for all your work on MacVim.

[ychin]

You can now grab the latest dmg installer from CI builds (#1532). https://github.com/macvim-dev/macvim/wiki/Installing/ has also been updated.

Note that the build is unsigned/non-notarized so only use this if you really want to check something out and I do not recommend using this as the main channel to get MacVim updates.