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:

• 2PM UTC
• 5PM UTC

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.

CUDA 11.8 is the last holdover from the old days before conda-forge switched to the new and shiny CUDA 12+ infrastructure, where the CUDA toolchain is provided as native conda-packages, rather than a blob in an image.

For CUDA-enabled feedstocks, we've been building both 11.8 and 12.6 by default for a while now, but many feedstocks (notably pytorch, tensorflow, onnx, jax etc.) have dropped CUDA 11.8 for many months already.

Due to various constraints (details below), we are dropping CUDA 11.8 as a default version in our global pinning on June 5th. It will still be possible to opt into building CUDA 11.8 on a per-feedstock basis where this is necessary or beneficial.

NumPy 2.0 was a big change (the first major version in 15 years). For more than a year, we have been migrating feedstocks from NumPy 1.x to NumPy 2.x, and while not every affected feedstock has been done, we are planning to conclude the migration in one week. Note that NumPy 2 support is required for feedstocks that intend to support Python 3.13 and above.

For feedstocks that are not compatible with v2.x yet, this means you will have to add

numpy:
  - 1.26  # or 1.25

to your recipe/conda_build_config.yaml, and then rerender. Pins below 1.25 are not possible if your feedstock supports Python 3.12, as NumPy 1.25 was the first version with support for that Python version (and it will not be possible going forward to pin different NumPy versions for different Python versions).