Homebrew
macOS 12 unsupported? #5603
-
Output of
|
Beta Was this translation helpful? Give feedback.
Replies: 8 comments 44 replies
-
|
The current latest macOS 12.x version, 12.7.6, is expected to be the last update for Monterey. macOS 15 releases on Monday alongside macOS 13.7 and macOS 14.7 and Apple support only 3 macOS versions at a time (so 13, 14 & 15). We too only have CI testing resources to support 3 macOS versions. We've reallocated our macOS 12 CI to be macOS 15 yesterday. |
Beta Was this translation helpful? Give feedback.
-
|
Can you point to announcements they've made in the past about dropping support? When and where did they announce that Big Sur was no longer supported? |
Beta Was this translation helpful? Give feedback.
-
|
Apple doesn't make announcements about dropping support. They just stop shipping updates. As @Bo98 said: Apple's policy on this has been consistent for the last 12 years. You'll notice that when macOS 15 was released we also received macOS 14.7 and macOS 13.7. If Apple was going to change their policy then we should've seen a Monterey update. There is no point in arguing this. We only support the 3 latest releases of macOS. |
Beta Was this translation helpful? Give feedback.
-
Kinda disappointing that dropping bottle download support also for Monterey & older macOS releases has the effect of codifying Apple's Planned Obsolescence into this Open Source project. Of course, it's understandable that everyone has limited time and even GitHub Actions runners eventually drop "support" for old macOS releases. However, dropping "support" from a maintainer's or developer's perspective can be a different and orthogonal concept to dropping "support" through pre-built old bottled versions. The maintenance burden to support old macOS versions via pre-bottled software would be much lower and have trivial impact when compared to dropping "support" for compiling everything from scratch & following Homebrew development from latest In other words: The concept of "support" can be decoupled into at least three separate concepts:
For concept number 1, this could be trivially done by locking the Homebrew repos + Taps to a specific last known In the case of conflating concepts 1 & 2 together, it creates an unintended scenario for users, as described below: There currently exists an unfortunate tragedy of the commons type of scenario given that users will eventually always end up stuck on old macOS releases due to old Apple hardware which gets locked to some macOS release (e.g. Monterey or below). As a result, even trying to use old hardware becomes unsustainable when every Homebrew install eventually becomes a compile rather than simple archived binary bottle install. Apple of course wins yet again, laughing all the way to the bank. Meanwhile, we end up with old hardware using much more energy + CPU cycles for each user to compile all the software every time for each and every user. Also, eventually due to the same issue this hardware becomes unusable with Homebrew-packaged software prematurely before its actual physical breakdown, thus becoming e-Waste. In the grand scheme of things, this pattern of planned obsolescence is arguably unsustainable from a civilization-level and also energy & ecological perspective. So, it's rather unfortunate to see Homebrew dropping the binary pre-packaged bottles for old releases so soon, resulting in the above scenario which we observe at present with Monterey. |
Beta Was this translation helpful? Give feedback.
-
|
To be clear: we have not gone and deleted all macOS 12 existing bottles (4.7k formulae still have macOS 12 bottles). We're just not building new bottles for new versions anymore. We do not have the CI infrastructure to support four OS versions - the moment of transition was when macOS 15 bottles started being built instead. It's not a grand climate change conspiracy like you think it is. Of course in the ideal world of infinite resources we would build bottles for every macOS possible, but that world unfortunately doesn't exist. We already try our best to support the build-from-source path all the way back to 10.11 El Capitan rather than hard cutting off support entirely. Although build from source is indeed slow and not great and we do not test it in CI (which is why we say it's unsupported), we do accept community contributions to fix any problems that people face while on this path. You can, as you say, choose to freeze the version list at the point macOS 12 bottles stopped being built if you do not wish to install newer versions. Such decision is up to individual users. |
Beta Was this translation helpful? Give feedback.
-
Seems that some other connotations are being supplanted or rather "reading too much into" what I was trying to say.1 To be clear: I'm merely trying to shine some light on the reasons why the community might desire "support" as in "can the tool install things on old macOS" via pre-built bottles + Homebrew (frozen at some point in time or otherwise). I figured it was worth pointing out and discussing what could be done in order to provide a more sustainable and lasting approach towards old hardware, rather than going along with Apple's planned obsolescence timeline.
Quite understandable, and indeed the availability of GitHub Actions' CI/CD Runners does impact what is possible given their timeline and Apple's timeline. It's always good to set expectations about this and what users can expect to be "supported" as in the meaning "do the maintainers use/test/build on this old macOS?" It's good to know that community contributions can still be accepted and help in this area. 👍
Yes, I'll probably experiment with this at some point. I think the current scenario that I'm observing is due to Homebrew's auto-update happening while coinciding with the change from building new bottles for latest available (and supported on my old Early-2015 MacBook), macOS Monterey
Seems that some others were caught off-guard also, but at least I knew what it meant and observed the symptoms of everything newly installed starting to be built from source (very slowly on the old MacBook). Footnotes
|
Beta Was this translation helpful? Give feedback.
-
https://dortania.github.io/OpenCore-Legacy-Patcher/VENTURA-DROP.html UPD: A1707(2016) Successfully updated to macOS Sequoia |
Beta Was this translation helpful? Give feedback.
-
|
has homebrew just annihilated my monterey install or is it still safe to use now since I ran Right now I am of the impression that running upgrade literally overwrote my homebrew installation with lots of imcompatible things. if that is not the case, then I will sigh a big relief, but its not clear to me what just happened. Feels like the rug has been pulled out from under me. I understand I'm a dumb naive user and doesn't understand the details, please help me make sure my homebrew installed apps are still safe to use. otherwise I guess I have to remove it all and switch to something else? or is there a way to remove it all and then reinstall it with some flags set so that it will only install the latest known good versions of most things? It's not at all clear what I am supposed to do at this point to ensure these various software continue to function. the current upgrade procedure is indeed taking a VERY long time to go...I guess its recompiling things from scratch or something, which i don't have a problem with if it will produce good results, but if its overwriting my installs with incompapatible things..that's a problem probably I would prefer to have it setup so that it will download any install any frozen binaries as they exist but NOT try to recompile new source.. how do I configure it so that I could theoretically reinstall everything get all the binaries that are still available..and not try to recompile new sources which may or may not be compatible or I may or may not be able to even compile? |
Beta Was this translation helpful? Give feedback.
-
Yes, that's exactly what it's doing: compiling everything from scratch. What I've observed in this case is that Homebrew stops installing pre-built "bottles" because there are no longer new versions of packages being built. This is because GitHub Actions deprecated their Monterey CI/CD runners, so the automatic builds of new software is no longer possible through this build pipeline. When a new package is released in On a client macOS system: Homebrew sees that no pre-built bottles are listed in the newly updated Formula. Homebrew then begins building any new versions of that software from source code from that point on. This can be a long process, as anyone with prior experience with a rolling-release source-based Linux distro (e.g. Gentoo) can attest. If the software builds successfully, including all dependencies up the chain for each package installed, then it will usually produce good results. However, if there is a compile error in some package, then you're kinda on your own to try and solve it. If you end up in that situation, and solve the problem, Homebrew might accept the patches or build fixes needed, just as long as they don't break the builds for new macOS versions. It's currently well-communicated through the CLI not to expect support for old macOS versions, and the warning text makes it pretty clear not to create GitHub issues for unsupported macOS. (I'm not too happy about it either, but it is the way it is 🤷)
This would be nice to be able to do easily, but it's currently unsupported by Homebrew. It might be possible to revert back to the last Warning I've not tested this extensively yet... but in theory it should be possible to "freeze" Homebrew at the last version supporting Monterey. Any Formulae with pre-built bottles would then install those old versions more quickly, without having to resort to building from source. To go about doing this:
When using a frozen Homebrew git tree, you will probably want to set at least The no-cleanup options can be helpful to avoid deleting locally cached bottles. These can be backed up elsewhere and used to re-install the packages independently of whether they are available on Homebrew's GitHub Packages repo. It can also be helpful to archive them on a local repo server. Hope this helps! Footnotes
|
Beta Was this translation helpful? Give feedback.
-
This is inaccurate. We perform all builds on our own managed-CI infrastructure using self-hosted runners to interface with GitHub. As stated elsewhere in this discussion, this infrastructure is limited in capacity, so we can only build on the 3 latest versions of macOS.
Also as stated elsewhere in the thread, we do not remove old bottles. Any existing Monterey bottles will remain. The issue is simply that new versions of software do not have bottles built, so users are stuck on old versions of the software as well. "Freezing" Homebrew on an old version in order to use old versions of precompiled software on an unsupported OS is certainly a choice that one can make, but a configuration like this is ripe for getting your entire system owned. Users are free to do what they want, but I'd hope common sense would prevail as to why this is a terrible idea. |
Beta Was this translation helpful? Give feedback.
-
Ah, makes sense! That's good to know. Given this, I had made the assumption that the standard GitHub Actions macOS runners were being used for the most part. I see that here there is an environment variable controlling whether to use standard GitHub runners or self-hosted runners. Theoretically, that could open the door to supporting older macOS versions... so long as those self-hosted runners could reset to a clean state without needing Apple's support (e.g. VM snapshot resets).
Yeah, I realized that while digging into the details to provide the answer above. I see that the bottle archive files themselves are hosted on GitHub Packages. So, that means these files themselves are not removed. Only the Ruby DSL syntax within the Formulae is eventually dropping the SHA256 hash and pointer to those old bottles. So, effectively
Indeed. I think we can both agree that the situation isn't ideal. Yet still, people will eventually end up in the same situation due to Apple's deprecation & hardware support policy and have to deal with it somehow. Freezing Homebrew is one possible solution, which of course has the security risks that you've pointed out. There might be other solutions such as forcing a macOS upgrade via OCLP, using Linux instead (although Asahi only supports Apple silicon), and maybe some other solutions that I'm not thinking of yet. 🤷 |
Beta Was this translation helpful? Give feedback.
-
|
whatever homebrew did in regard to dropping this support, it proceeded during upgrade, without asking; to install over the top of my monterey system all manner of allegedly potentially incompatible things (I think?)..which I can't even fix now since homebrew has dropped this version. I will definitely cease to use homebrew due to this policy and I'm extremely disappointed. homebrew team cannot be trusted. congradulations |
Beta Was this translation helpful? Give feedback.
-
Yeah, allowing for a total package manager ecosystem freeze would definitely be a tradeoff. The security aspect is one. I'm sure that there would be other aspects to consider, pros & cons to doing this. Yet, given that many people might only use old hardware at home or on a trusted network, it's likely that many users would be willing to accept the risks. Many package managers on Linux distros allow for holding back or version-pinning specific packages. In some closed-loop network scenarios I've also seen companies use a local package repo mirror or cache that they can freeze at some point in time if a hardware vendor or official OS repo drops support. Of course, the legends of old machines running in a closet somewhere, or companies still running decades-old COBOL code are indeed a reality. So things like this are not as uncommon as we'd hope or like to think. |
Beta Was this translation helpful? Give feedback.
-
|
[Disclosure: I'm not a Homebrew maintainer, and don't speak for them. I do, however, speak from (a) experience doing similar things to what I describe below, and (b) observing users' posts in Homebrew on GitHub.]
If I'm reading you correctly, that's already possible, sorta, on an individual basis:
The downside: bottles may not hang around forever, so when you finally decide to Now, it sounds like you're asking for an "auto EOL" mode to be officially supported, viz.:
That's a helluva lot of work for letting a few users "stand still in time", and I'd bet real money that the recurring maintainer workload also skyrockets, with people now filing issues against obsolete bottles ("hey, xyzzy is already at v4.0, why am I only see v2.3?!?!"), requests to update formulae to match the capabilities of the same (but updated) formula on the official tap ("hey, xyzzy is missing bunkolib, so it can't do frizzypop like the upstream docs say it should"), etc. so forth. It turns out very few people are content with actually "standing still in time", despite saying that's all they're asking for. Of course, a kind soul could host their own "core tap" for, say, Monterey. That would probably involve the following:
And then there's the open Internet, where "I just want to be able to install xyz on my outdated system" invariably leads to "now I want the latest and greatest xyz on my outdated system, it's open source, why are you making it so hard?!?!" |
Beta Was this translation helpful? Give feedback.
-
|
I'm just gonna run the updates, let them compile and the first time something actually breaks I will switch to Macports that seems to be more supportive and understanding of folks that need for any reason run older hardware that can't keep up with apple's policy. Nothing I have seen here indicates a practical way to use homebrew on Monterey and rely on it. Might work sometimes and sometimes it won't. Fortunately I don't usually need to install new stuff by now anyway. I will just avoid using it or turn to macports if there is something I need to do. I feel this issue is going to be more prevalent right now and for a few years then it will be in the further future ahead because of the transition to apple silicon. Also Apple made a series of very very capable Mac Pro machines a decade ago and some people even upgraded the Xeon processors beyond what Apple initially sold, they have enough cores to remain very relevant machines even today 10+ years later. They were highly expandable and upgradable. Now Apple is making machines designed to be traded in more more and not upgradable, with an aggressive policy about deprecating older ones. So in the future people won't keep using them forever. But the Macpro line from 10 years ago, particularly 5,1, are still in major use all over the place thanks to opencore. You can label us as "being stuck" all you want but the simple truth is this hardware is still valuable, useful and definitely still being used like crazy by thousands and thousands of people; even if they can't go past Monterey and even if home brew won't support it either, they are going to keep living on for quite a while. In the future this will not be the case because Apple is now making machines more disposable and it will be a different story later. Then the three year rule may make more sense. Right now it's a severe nuisance |
Beta Was this translation helpful? Give feedback.
-
I can guarantee that as long as I, personally, am involved in this project and our other maintainers continue respecting my perspective and input as an experienced security professional that this will never happen. Much like we do not allow disabling of macOS security features for software distributed with Homebrew, we will not make it easy to do something so absurd. If someone wants to do something like this they will have to go through the effort to sort it out themselves, at which point hopefully the light will click and they'll think "Wow, this sucks. Maybe I should do something about the underlying problem?" My experience in responding to users in these Discussion posts tells me that's unlikely, but I'll keep hoping.
Yes, this is a reality of the world. That doesn't mean we need to be okay with it, or offer any kind of support for those making the decision to use unsupported configurations.
This is not a goal of the Homebrew project.
I think we're both willing to bet that anyone who tries this would burn out incredibly quickly.
I'm not sure why you're still commenting here. You've made the point you want to make and we disagree with it. Just go use MacPorts. It's a perfectly competent package manager with support for older versions of macOS. Supporting old versions of macOS is not a goal of the Homebrew project like it is for the MacPorts project. I will say though, if you continue posting like this over there I'm sure their maintainers will get just as tired of you as we are.
Yeah, it will. The days of Intel Mac devices are numbered. It's just like the people who threw tantrums when Apple moved from PowerPC to Intel. Times change, progress happens. Stop living in the past. No one is interested in hearing you whine about how awesome your 10 year old Mac Pro is, especially in a space where unpaid volunteers are using their free time to support one of the most critical open source projects on macOS. No one working on Homebrew gets a salary for doing this. We do it because we love the project and want to support our users. We can't help the 90% of users on supported configurations if we are investing large amounts of time on the 10% who refuse to live with us in modern times. It's so disheartening to come into discussions and deal with people like you calling us stupid and raging out because you want to be treated special. Read the docs, and if this project doesn't work for you, go elsewhere. I'd like to suggest you read this article before you speak with any other open source maintainers. It should help you get into the right headspace for why the way you are acting is completely unacceptable: https://mikemcquaid.com/open-source-maintainers-owe-you-nothing/ |
Beta Was this translation helpful? Give feedback.
-
Yes, it appears that we both completely understand the challenges and context surrounding this issue. In order to assist @steveschow with the Monterey EOL situation, I outlined a method that's effectively equivalent to yours, though a bit tailored to his unique situation (See this very similar approach here). I hope that this helps!
I'm not so sure about auto EOL actually. Assuming that "auto" means "automatically enabled" as in it would be the default behavior. I'm not sure that such an auto EOL mode would be what most users would expect. Especially given that the current default behavior now is to start simply building from source and continuing to update from non-bottled package definitions. The steps you proposed would definitely be an effective plan to support this mode. One tweak would be to allow this to be Opt-In for the users who want this behavior. Ideally, before the EOL date, it would be made known through For example, Apple announces when macOS versions stop supporting old hardware. Likewise, GitHub has been good about announcing macOS runner EOL dates so far. So, once some tooling is in place it could be as simple as signaling the EOL date in advance and adding some git tags or branches (any
That's a valid concern. Of course, some initial time investment would be necessary to develop the feature. However, once it's working then maintenance could be made simple as described above in a "set and forget" sort of way. To avoid the usual flood of users filing issues, it would be important to set expectations well in advance of the EOL date and communicate the possible "EOL freeze" feature and what exactly it does. Good communication would be key to avoid catching users off guard (as appears to have happened already as the impetus for this discussion). Making the feature "Opt-In" would avoid having the entire Homebrew user population be caught in a frozen state unexpectedly since due to the precedent of the default behavior they would not be expecting this.
Ok, that's fair. As a maintainer, you have the right to say no. Your perspective as a security professional seems to place this feature proposal at odds with the goal of security updates. That's a logical conclusion, of course, and indeed there would be risks that the user would be assuming when freezing updates. You've made it clear that you're personally not interested in this feature. That's fine. Nobody is asking you personally to develop or maintain it. There are likely others in the community who still might want to, or maybe not, and that's ok too.
Objectively, there is nothing "absurd" with what is being proposed. Due to circumstances outside the user's control (Apple's EOL policy, GitHub runners, etc...), they are being subjected to a timeline of hardware renewal which may not align with their individual budget or goals. Given that Apple hardware prices are often out of reach for most people on fixed or low income, it may not be possible for users to be forced to upgrade on a timeline outside their control. Doing so indefinitely might leave them in debt, or without food or housing, given the socioeconomic circumstances we find ourselves within, in this society. Given the above situation, it's understandable that a reasonable person might want to simply freeze updates to their old hardware so that they might be able to keep using it a bit longer. The latest and greatest version of everything isn't always desirable, nor what's best from a non-security perspective. That's ok too, so long as users understand the risks and their own individual goals.
It'd be quite unusual for someone to actually be "living in the past". Last I checked, that would only be possible if someone were traveling close to the speed of light with the resulting time dilation of two reference frames. 🤔 😄 All joking aside... From what I've read, nobody's advocating a Luddite-esque perspective here for "living in the past". In fact, the current discussion seems centered around circumstances that are happening in the present:
It's a clear case of cause and effect, bubbling down from Apple's decision. Users are understandably upset, given that not everyone agrees with Apple's (notorious) habit of planned obsolescence. Old hardware isn't that great compared to newer Apple silicon due to advances made, Moore's law, etc... Nobody is saying their old hardware is that awesome compared to the newer models. It seems that one complaint was that the pre-bottled software was dropped, causing old slower hardware to need to compile everything, taking a lot of time for those users, and causing potential inconveniences (build errors, time & energy spent compiling, etc...) The main point seems that some users spent quite a bit of money only a few short years ago on expensive hardware, and they want to get more use out of it before being forced to spend more money on new hardware. Seems reasonable to me. 🤷
It'd be interesting to see the statistics on what hardware the user population has. Then we could have some hard data to draw conclusions from. Are there any hardware surveys or stats available for the Homebrew community?
Yeah, I'm not that happy or okay with it either. I'd much prefer if Apple would take a less forceful approach towards deprecating old hardware, and simply allow upgrades to newer supported versions of macOS. That would be the easiest route for still being able to use Homebrew with bottled software. Apple has the money and resources to support it. Meanwhile, Homebrew has unpaid volunteers and does have quite a bit of GitHub Actions pipelines and automation to help the community. However, the Homebrew project is still subjected to the same situation due to Apple & then GitHub's EOL policy for macOS Actions runners. When compared to how Microsoft Windows treats backward compatibility even for a PC hardware ecosystem with a lot of "hardware fragmentation" (e.g. permutations of hardware to support), and the near infinite possibilities of running Linux on old hardware, Apple leaves quite a bit to be desired. Especially so since their hardware permutations to support are much more limited. Either way, it's mostly out of our control and we simply must deal with the present situation as it is. Complaining about Apple is easy to do, but as ineffective as "Old Man Yells at Cloud" in invoking change. Apple will continue to seek profit-driven rewards and is not likely to change their hardware EOL policy anytime soon. Especially so since they just made a major CPU architecture jump from |
Beta Was this translation helpful? Give feedback.
-
|
so I didn't know about this change and came back and saw a very long and slow |
Beta Was this translation helpful? Give feedback.
-
|
It's less of what we "want" to do, and more of the realities of package management. We do not have the CI resources or maintainer interest to invest in older macOS versions that have increasingly fewer users. This is also not the right place to litigate your complaints about how Apple operates. We are focused on the sustainability and health of Homebrew, and want it to be available for years to come. For us, that means supporting versions of macOS that receive active security support from Apple. Support for Intel macOS will probably end within the next few years, so our focus has shifted, and I cannot recommend you stay on an unsupported OS because you find the hardware to be "perfectly good". |
Beta Was this translation helpful? Give feedback.
-
Neither Apple nor Homebrew cut off support after three years. Both Apple and Homebrew support the latest three versions of macOS. These are not the same. To see this, note that macOS Ventura, the oldest supported OS, runs on at least some Macs introduced in 2017. This means that there are about 7 to 8 years of support for any given OS. |
Beta Was this translation helpful? Give feedback.
-
|
If you don't want to litigate then why do you throw out a last criticism and lecture about using perfectly good hardware and perfectly good macOS version? Macports looks better and better with that kind of attitude coming from you. Good luck with homebrew |
Beta Was this translation helpful? Give feedback.
-
I'm sorry if it came across as insincere, but I genuinely am hoping to impress on you that this is a bigger issue than Homebrew. It's neither criticism nor a lecture; it's a sincere hope that you will not stay on macOS Monterey simply because it runs on the hardware. Every year that goes by will result in fewer and fewer applications supporting Monterey, and security issues piling up with 0 chance of a fix. Rather than switching package managers because your system is too old, wouldn't it be better to try and address that underlying issue instead? Just hoping to inject a bit of a security perspective into the situation. MacPorts is a great project, and I hope it works well for your use case. |
Beta Was this translation helpful? Give feedback.
-
|
Yes, this is perfectly understandable from an engineering perspective given the situation with both Apple and GitHub Actions dropping support for Monterey.
Indeed, it would be my hope too to be able to upgrade my old Intel-based macBook past Monterey. Alas, Apple has decided to stop supporting this old hardware model and it's not possible to upgrade past Monterey (unless one considers the after-market OCLP path, or else use Linux). With the goal of Permacomputing-like concepts in mind... I'd be interested in hearing thoughts & feedback about this potential suggestion. 🤔 |
Beta Was this translation helpful? Give feedback.
This comment was marked as off-topic.
This comment was marked as off-topic.
-
|
As stated above: this is not the place to complain or argue about Apple's policies. This thread is about macOS 12 Monterey support. |
Beta Was this translation helpful? Give feedback.
-
|
/usr/bin/sudo /usr/sbin/chown -R zhaodongjian:admin /opt/homebrew please,what problem is it?i am macos 12.7.6，i hope bro can help me |
Beta Was this translation helpful? Give feedback.
-
|
Has everyone encountered this situation? |
Beta Was this translation helpful? Give feedback.
-
|
I haven't seen that myself. A quick search for that error turns up this. Do any errors show up like: If so, it might be that you need to update the macOS Otherwise, I'm not sure 🤷 |
Beta Was this translation helpful? Give feedback.
-
|
You can try setting |
Beta Was this translation helpful? Give feedback.
-
|
macOS 12 cannot install xz now, it makes a lot of packages cannot be installed like gcc, when I try to update it, it can only be updated to 4.1.25 due to new brew need macOS 13+ I feel very regrettable, it seems that I can only install various packages manually in the future :( |
Beta Was this translation helpful? Give feedback.
-
|
Homebrew itself can absolutely be updated to the latest version (4.4.15 as of this writing), even on platforms for which bottles are no longer built. Here's the proof from my Mac mini: You should not still be stuck with Homebrew 4.1.25, unless your |
Beta Was this translation helpful? Give feedback.
-
|
to be asinine about this whole situation homebrew itself ie. github.com/homebrew/brew could be changed to support older macos versions by setting the deployment targets when building bottles aka how i believe macports does it. so if the box building the bottle had the oldest available SDK say 10.14 then building on the latest x86_64 / amd64 supported mac, in theory that bottle would run on macos 10.14 on newer, but would require some significant changes to how homebrew operates, and doubt anybody would want to take on those changes. |
Beta Was this translation helpful? Give feedback.
-
|
Assuming the build-with-10.14-SDK works, the bottles still can't be tested against 10.14 without a running instance, so I don't see why Homebrew maintainers would want to go down this road. That would just invite a flood of issues from 10.14 users that they can't resolve. |
Beta Was this translation helpful? Give feedback.
The current latest macOS 12.x version, 12.7.6, is expected to be the last update for Monterey. macOS 15 releases on Monday alongside macOS 13.7 and macOS 14.7 and Apple support only 3 macOS versions at a time (so 13, 14 & 15).
We too only have CI testing resources to support 3 macOS versions. We've reallocated our macOS 12 CI to be macOS 15 yesterday.