FoundationDB now defaults to major version 7.

I was directed here from the Staging channel. I’ve got question about how LLVM update for Darwin fits into the release process. I know Darwin isn’t a tier 1 platform, but I don’t know what amount of breakage is expected or tolerated.

• Is there a point at which it should be reverted to reduce the breakage on staging-next; or
• Is there a threshold (such as less than X dependents) where stuff can be allowed through broken on Darwin (perhaps marked en masse on the release branch) and fixed with backports?

Personally, I have no idea and no real opinion, I don't know what is the type of software people tend to use on Darwin with Nix, if I had to say anything:

• someone who cares about Darwin has to make the call for the reverts on staging-next based on their time, expected folks who will help on Darwin fixes, etc.
• the threshold thing seems weird to me, I would pursue a set of leaf packages that you always want to work in general (or is required for channel bump for example).
• I'd generally move any large scale changes to after the release otherwise chances are that you will slip and it will be hard to fix things with all the backports you need

In reply to @raitobezarius:matrix.org

Personally, I have no idea and no real opinion, I don't know what is the type of software people tend to use on Darwin with Nix, if I had to say anything:

• someone who cares about Darwin has to make the call for the reverts on staging-next based on their time, expected folks who will help on Darwin fixes, etc.
• the threshold thing seems weird to me, I would pursue a set of leaf packages that you always want to work in general (or is required for channel bump for example).
• I'd generally move any large scale changes to after the release otherwise chances are that you will slip and it will be hard to fix things with all the backports you need

From a Darwin perspective, reverting would be non-ideal. Aside from pushing back the work on the SDK stuff, it risks breaking things using older versions of clang due to incompatibility with clang 16. I’m thinking nodejs and some other stuff that is pinned to clang 15. libc++16 is backward compatible, but libc++ 11 may not be forward compatible enough. There’s also the issue of things that already are not compatible with the clang 11 toolchain (for various reasons).

The threshold was proposed as an attempt at an objective-ish cutoff. I’ll look at what’s in the Darwin channel bump requirements to see if any of those packages need fixed. If they’re all okay, I think it’d be reasonable to tolerate the breakage in the short term provided that fixes are backported. The rebuilds should all be low, so everything would be able to go into master directly.

The only large change currently targeting the release is a fix requested by Haskell maintainers to address the libc++abi issue for Haskell in their generic-builder.nix rather than just in the breaking packages (due to end users using the Haskell infrastructure to build code outside of nixpkgs that may be impacted by the issue). It was indicated they preferred rebuilds to having end-users with broken code (see https://github.com/NixOS/nixpkgs/pull/266172).

There are a few others such as the CF change (because mixing CF and CoreFoundation results in crashes, and CF is just such a maintenance burden) and Darwin cross-compilation, but I wasn’t planning to have those in the release unless something really needed them. Currently aws-sdk-cpp, arrow-cpp, and python3Packages.cherrypy are known not to be buildable on x86_64-darwin running macOS 14. The first two have made it through Hydra, but the last one is getting unlucky with the builder it gets. If it gets lucky, I think that’s okay. Rebuilding all of Darwin (and it would be a completely full rebuild due to touching the first stage of the Darwin bootstrap) should be avoided at this point.

In reply to @raitobezarius:matrix.org
Also, I know you are probably among the folks that does a lot of Darwin work and I don't know how much "colleagues" do you have to help in that endeavor, I would be mindful of your energy