Blog | conda-forge | community-driven packaging for conda

With Python 3.10 reaching end-of-life in Oct. 2026 and Python 3.15 being released the same month, we have decided to drop 3.10 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 begin rolling out support for 3.15.
We have added a new admin webservices command to convert recipes to the v1 format. You can use this command, @conda-forge-admin, please convert to v1 in the title of an issue to open a new PR or in a comment on a PR to push to an existing one. The conversion process is done by conda-recipe-manager, and any errors in the conversion process will be posted as a comment to the PR.
As part of our regular toolchain updates, we're planning to update the baseline versions of GCC (our default compiler on Linux) to v15 and of Clang (default on macOS) to v21, in one week.
For more details, see https://github.com/conda-forge/conda-forge-pinning-feedstock/pull/8795.
We need to do maintenance on the feedstock GitHub teams that requires some downtime. During this downtime, feedstock teams will not be updated. If you need help with an urgent, feedstock team-related maintenance item, please contact @conda-forge/core.
conda-forge is now able to enjoy extended concurrency limits for Github Actions, and thus we can finally use it as CI provider for package builds. To enable this functionality on Linux, rerender your feedstock with conda-smithy 3.57.1 or later. Windows and macOS still default to Azure for the time being (check conda-forge.github.io#2771 for updates).
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).