# Gradle Release Notes

We are excited to announce Gradle 9.2.0-20251001020542+0000 (released 2025-10-01).

This release introduces support for running Gradle on Windows ARM (ARM64) devices, making it easier to build on Apple Silicon and other ARM-based systems.

It also improves the publishing API with new ways to define and publish custom software components.

In addition, the Daemon toolchain has been promoted to stable.

We would like to thank the following community members for their contributions to this release of Gradle: Adam, Björn Kautler, hasunzo, HYEON, Hyunjoon Park, HYUNJUN SON, Jendrik Johannes, Kirill Gavrilov, Madalin Valceleanu, Martin Bonnin, Mikhail Polivakha, Na Minhyeok, Philip Wedemann, Philipp Schneider, Róbert Papp, Simon Marquis, TheGoesen, Vincent Potucek, Xin Wang.

Be sure to check out the public roadmap for insight into what's planned for future releases.

## Table Of Contents

## Upgrade instructions

Switch your build to use Gradle 9.2.0-20251001020542+0000 by updating the wrapper in your project:

    ./gradlew wrapper --gradle-version=9.2.0-20251001020542+0000 && ./gradlew wrapper

See the Gradle 9.x upgrade guide to learn about deprecations, breaking changes, and other considerations when upgrading to Gradle 9.2.0-20251001020542+0000.

For Java, Groovy, Kotlin, and Android compatibility, see the full compatibility notes.

## New features and usability improvements

### Windows on ARM support

Gradle now supports running builds on Windows ARM (ARM64) devices.

This makes it possible to run Gradle on Windows virtual machines hosted on Apple Silicon and other ARM-based systems.

### Publishing improvements

Gradle provides APIs for plugin authors and build engineers to define and customize the software components their project produces when publishing them.

#### New `PublishingExtension.getSoftwareComponentFactory()` method

Gradle now exposes the `SoftwareComponentFactory` service directly through the `publishing` extension. This makes it easier to create and publish custom components.

In most builds, a publishable component is already available. For example, the Java plugins automatically provide a `java` component. But if you’re authoring a plugin and want to publish something custom without depending on the Java plugins, this new method provides a straightforward way to do so:

    plugins {
        id("maven-publish")
    }

    val consumableConfiguration: Configuration = getAConfiguration()

    publishing {
        val myCustomComponent = softwareComponentFactory.adhoc("myCustomComponent")
        myCustomComponent.addVariantsFromConfiguration(consumableConfiguration) {}

        publications {
            create<MavenPublication>("maven") {
                from(myCustomComponent)
            }
        }
    }

#### New provider-based methods for publishing configurations

Two new methods have been added to `AdhocComponentWithVariants` that accept providers of consumable configurations:

- `void addVariantsFromConfiguration(Provider<ConsumableConfiguration>, Action<? super ConfigurationVariantDetails>)`
- `void withVariantsFromConfiguration(Provider<ConsumableConfiguration>, Action<? super ConfigurationVariantDetails>)`

These complement the existing overloads that require an already realized configuration.

By accepting providers, configurations can now stay lazy and are only realized when needed for publishing:

    plugins {
        id("base")
        id("maven-publish")
    }

    group = "org.example"
    version = "1.0"

    val myTask = tasks.register<Jar>("myTask")
    val variantDependencies = configurations.dependencyScope("variantDependencies")
    val myNewVariant: NamedDomainObjectProvider<ConsumableConfiguration> = configurations.consumable("myNewVariant") {
        extendsFrom(variantDependencies.get())
        outgoing {
            artifact(myTask)
        }
        attributes {
            attribute(Category.CATEGORY_ATTRIBUTE, objects.named<Category>("foo"))
        }
    }

    publishing {
        val component = softwareComponentFactory.adhoc("component")
        // New overload accepts a provider instead of a realized configuration
        component.addVariantsFromConfiguration(myNewVariant) {}

        repositories {
            maven {
                url = uri("<your repo url>")
            }
        }
        publications {
            create<MavenPublication>("myPublication") {
                from(component)
            }
        }
    }

With this approach, `myNewVariant` is only realized if the `myPublication` publication is actually published.

## Promoted features

Promoted features are features that were incubating in previous versions of Gradle but are now supported and subject to backward compatibility. See the User Manual section on the "Feature Lifecycle" for more information.

The following are the features that have been promoted in this Gradle release.

### Daemon toolchain is now stable

The Daemon toolchain, introduced as an incubating feature in Gradle 8.8, has been improved and is now stable. It no longer prints an incubation warning when used.

## Fixed issues

## Known issues

Known issues are problems that were discovered post-release that are directly related to changes made in this release.

## External contributions

We love getting contributions from the Gradle community. For information on contributing, please see gradle.org/contribute.

## Reporting problems

If you find a problem with this release, please file a bug on GitHub Issues adhering to our issue guidelines. If you're not sure if you're encountering a bug, please use the forum.

We hope you will build happiness with Gradle, and we look forward to your feedback via Twitter or on GitHub.