We will bump the minimum MacOS version from 10.13 (released in Sept. 2017, end-of-life since Dec. 2020) to 11.0 (released Nov. 2020, end-of-life since Sept. 2023) sometime next week.
This will not affect already-published artefacts, and you will not receive incompatible builds even when still using an older Mac. However, going forward, to be able to keep using the most recent packages from conda-forge, you will need to update your OS to at least 11.0.
Due to ongoing issues with the solver pulling in the external MPI builds ahead of the real packages,
we have moved the external builds to a new label, conda-forge/label/mpi-external. The packages on this
label replace the old MPI packages with external in their build strings. These old packages have been labeled
as broken. Follow our documentation
to update to the new syntax.
Tegra devices are system on chip (SOC) devices used in robotics and other mobile applications. They are a Linux ARM (aarch64) platform variant which must be targeted separately from Server Base System Architecture (SBSA) ARM when compiling for CUDA 12.x and earlier. Non-NVIDIA feedstock maintainers may now build Tegra variants for their CUDA 12.9 packages if they choose by following these directions.
This special Tegra variant is only relevant for packages still targeting CUDA 12.9 because starting with CUDA 13.0, supported Tegra devices are SBSA-compliant, so they do not need to be targeted separately.
Starting in 2026, the conda-forge core calls will merge with the conda community calls in a single timeslot. Instead of alternating weeks, from now on, both communities will share the same space every Wednesday. There are two rotating timeslots:
The first meeting in 2026 will take place on January 7th, at 5PM UTC. For more details consult our calendar.
The meeting minutes will be available in both conda.org and conda-forge.org, in the usual places.
Starting with conda-smithy 3.54.0, the generated build scripts for macOS
will no longer use the system SDK directory for downloading the SDK versions
we require, but will use a dedicated /opt/conda-sdks directory instead.
Users performing local builds will need to choose a writable directory,
and provide the path to it via the environment variable OSX_SDK_DIR.
This change may result in some build systems, particularly CMake, storing paths to this temporary build directory in installed metadata. Feedstocks will need to substitute the stored paths with path-agnostic solutions (for example, see substitutions in openpmd-api-feedstock) or the correct sysroot paths (for example, see substitutions in cartographer-feedstock).
We have made the conda-forge Discourse forum read-only. Please use the conda-forge Zulip chat instead.
With Python 3.9 reaching end-of-life in Oct 2025 and Python 3.14 being released the same month, we have decided to drop 3.9 from our default build matrix. This will be reflected in your feedstock configuration on the next rerender. The decision to drop support 1.5 months before its EOL is to avoid the strain on conda-forge CI while we add support for 3.14.
conda-forge by default uses OpenBLAS as its BLAS and LAPACK
provider on macOS as it was updated regularly and is the least
buggiest performant BLAS/LAPACK implementation.
macOS 13.3 updated the Accelerate framework after a long time with
improved support for LAPACK APIs and has fixes for long-time known
bugs in the older Accelerate's BLAS and LAPACK APIs.
conda-forge has added support for this
new Accelerate framework by using a shim library to expose its
functionality to most conda-forge packages including numpy,
scipy and pytorch.
You can use it by doing
conda install libblas=*=*_newaccelerate
As part of our regular toolchain updates, we're planning to update the default versions of GCC (for linux) to v14 and of Clang (for OSX) to v19, in one week.
For more details, see https://github.com/conda-forge/conda-forge-pinning-feedstock/pull/7421.
Microsoft's Visual Studio (VS) 2019 compiler has reached its end of life over a year ago. In the meantime, several projects have moved on and fail to compile with VS2019.
We are planning to update our default compilers on windows to the (fully compatible) successor VS2022 in one week from now.
This will not affect you as a general user of conda-forge packages on windows; the only potential impact is that if you are compiling locally with VS2019 against artefacts produced by conda-forge, you might be required to upgrade.
For more details see https://github.com/conda-forge/conda-forge.github.io/issues/2138.