many thanks @pp-mo 🍺 No concern at my end of (very DevOps-y technical) work, let me know if I can help in any way

I would prefer the delay and including a fix for #3678.

Any chance that a fix for #6188 can still be included? This is a pretty severe bug that affects cube and coordinate equality checks. I had a go at fixing it in #6325, but if you prefer to fix it in a different way that would also be great.

I would prefer ... including a fix for #3678.

hmmm... well so would we, and it was prioritised, but at present it is just looking like a bit of a blocker.
I'll keep you posted, I think that's the best we can promise right now.

Any chance that a fix for #6188 can still be included?

Well, I am looking into it again, but I need a bit of time ... so far trying to work out performance implications, whether they are serious and/or inevitable.

I looked at those a bit too and fixed the benchmarks in #6339 to get a more realistic report. I noticed a small inefficiency when looking at the profiling results that I think can be solved easily to compensate at least in part for the performance loss in the specific case used for the benchmark, so implemented that change in #6337.

Update 2025-03-06

We are still planning to cut a 3.12 release on Monday, i.e. 2025-03-10.

Remaining tasks:

• Make array equal work with masked Dask arrays and add tests #6325 After some considerable more effort from @bouweandela , this is now merged
• Bounds of derived variable are not read correctly #3678 unfortunately is still very much stuck without an acceptable solution. Though we do have a clear plan, it will just take more work
• Tolerant handling of standard_name and dimension coordinate loading #6338 ..
• .. and Combine cubes 2 #6334 :
  • I hope to have these also completed by Monday, but they are also still not certain

Many thanks !