<commit_before>## New and noteworthy

Here are the new features introduced in this Gradle release.

### Dependency substitution rules

In previous Gradle versions you could use a 'Dependency resolve rule' to replace an external dependency with another:

    resolutionStrategy {
        eachDependency {
            if (it.requested.group == 'com.deprecated') {
                details.useTarget group: 'com.replacement.group', name: it.requested.module, version: it.requested.version
            }
        }
    }

This behaviour has been enhanced and extended, with the introduction of 'Dependency Substitution Rules'.
These rules allow an external dependency to be replaced with a project dependency, and vice-versa. 

You replace a project dependency with an external dependency like this:

    resolutionStrategy {
        dependencySubstitution {
            withProject(":api") { 
                useTarget group: "org.utils", name: "api", version: "1.3" 
            }
        }
    }

And replace an external dependency with an project dependency like this:


    resolutionStrategy {
        dependencySubstitution {
            withModule("com.example:my-module") {
                useTarget project(":project1")  
            }
        }
    }

There are other options available to match module and project dependencies:

    all { DependencySubstitution<ComponentSelector> details -> /* ... */ }
    eachModule() { ModuleDependencySubstitution details -> /* ... */ }
    withModule("com.example:my-module") { ModuleDependencySubstitution details -> /* ... */ }
    eachProject() { ProjectDependencySubstitution details -> /* ... */ }
    withProject(":api")) { ProjectDependencySubstitution details -> /* ... */ }

It is also possible to replace one project dependency with another, or one external dependency with another. (The latter provides the same functionality
as `eachDependency`).
Note that the `ModuleDependencySubstitution` has a convenience `useVersion()` method. For the other substitutions you should use `useTarget()`.

### Support for Precompiled Headers

Precompiled headers are a performance optimization for native builds that allows commonly used headers to be compiled only once rather than for
each file that includes the headers.  Precompiled headers are now supported for C, C++, Objective-C and Objective-C++ projects.

To use a precompiled header, a header file needs to defined containing all of the headers that should be precompiled.  This header file is
then declared in the build script as a precompiled header.

    model {
        components {
            hello(NativeLibrarySpec) {
                sources {
                    cpp {
                        preCompiledHeader "pch.h"
                    }
                }
            }
        }
    }

Each source set can have a single precompiled header defined.  Any source file that includes this header file as the first header will
be compiled using the precompiled header.  Otherwise, the precompiled header will be ignored and the source file will be compiled in the
normal manner.  Please see the [userguide](userguide/nativeBinaries.html#native_binaries:preCompiledHeaders) for further information.

### Google Test support (i)

- TBD

## Promoted features

Promoted features are features that were incubating in previous versions of Gradle but are now supported and subject to backwards compatibility.
See the User guide section on the “[Feature Lifecycle](userguide/feature_lifecycle.html)” for more information.

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

<!--
### Example promoted
-->

## Fixed issues

## Deprecations

Features that have become superseded or irrelevant due to the natural evolution of Gradle become *deprecated*, and scheduled to be removed
in the next major Gradle version (Gradle 3.0). See the User guide section on the “[Feature Lifecycle](userguide/feature_lifecycle.html)” for more information.

The following are the newly deprecated items in this Gradle release. If you have concerns about a deprecation, please raise it via the [Gradle Forums](http://discuss.gradle.org).

### Changing a configuration after it has been resolved

TODO

## Potential breaking changes

### Distribution Plugin changes

Due to a bug in the distribution plugin (see GRADLE-3278), earlier Gradle versions didn't follow the general naming convention for the assemble task of the main distribution.
This has been fixed and assemble task name for the main distribution has changed from `assembleMainDist` to `assembleDist`.

### Removal of `componentSpec` project extension

As part of work on exposing more of the component model to rules the `componentSpec` project extension previously added by all language plugins via `ComponentModelBasePlugin` has been removed.
Currently component container can be only accessed using model rules.

### `model.components` cannot be viewed as

### Configurations that are task inputs are resolved before building the task execution graph

## External contributions

We would like to thank the following community members for making contributions to this release of Gradle.

* [<NAME>](https://github.com/Shad0w1nk) - Support GoogleTest for testing C++ binaries
* [<NAME>](https://github.com/lptr), [<NAME>](https://github.com/vigoo) and [<NAME>](https://github.com/vujevits) - implement dependency substitution for projects
* [<NAME>](https://github.com/lptr), [<NAME>](https://github.com/vigoo) and [<NAME>](https://github.com/vujevits) - implement dependency substitution for projects

## Known issues

Known issues are problems that were discovered post release that are directly related to changes made in this release.
<commit_msg>Removed duplicate line from release notes<commit_after>## New and noteworthy

Here are the new features introduced in this Gradle release.

### Dependency substitution rules

In previous Gradle versions you could use a 'Dependency resolve rule' to replace an external dependency with another:

    resolutionStrategy {
        eachDependency {
            if (it.requested.group == 'com.deprecated') {
                details.useTarget group: 'com.replacement.group', name: it.requested.module, version: it.requested.version
            }
        }
    }

This behaviour has been enhanced and extended, with the introduction of 'Dependency Substitution Rules'.
These rules allow an external dependency to be replaced with a project dependency, and vice-versa. 

You replace a project dependency with an external dependency like this:

    resolutionStrategy {
        dependencySubstitution {
            withProject(":api") { 
                useTarget group: "org.utils", name: "api", version: "1.3" 
            }
        }
    }

And replace an external dependency with an project dependency like this:


    resolutionStrategy {
        dependencySubstitution {
            withModule("com.example:my-module") {
                useTarget project(":project1")  
            }
        }
    }

There are other options available to match module and project dependencies:

    all { DependencySubstitution<ComponentSelector> details -> /* ... */ }
    eachModule() { ModuleDependencySubstitution details -> /* ... */ }
    withModule("com.example:my-module") { ModuleDependencySubstitution details -> /* ... */ }
    eachProject() { ProjectDependencySubstitution details -> /* ... */ }
    withProject(":api")) { ProjectDependencySubstitution details -> /* ... */ }

It is also possible to replace one project dependency with another, or one external dependency with another. (The latter provides the same functionality
as `eachDependency`).
Note that the `ModuleDependencySubstitution` has a convenience `useVersion()` method. For the other substitutions you should use `useTarget()`.

### Support for Precompiled Headers

Precompiled headers are a performance optimization for native builds that allows commonly used headers to be compiled only once rather than for
each file that includes the headers.  Precompiled headers are now supported for C, C++, Objective-C and Objective-C++ projects.

To use a precompiled header, a header file needs to defined containing all of the headers that should be precompiled.  This header file is
then declared in the build script as a precompiled header.

    model {
        components {
            hello(NativeLibrarySpec) {
                sources {
                    cpp {
                        preCompiledHeader "pch.h"
                    }
                }
            }
        }
    }

Each source set can have a single precompiled header defined.  Any source file that includes this header file as the first header will
be compiled using the precompiled header.  Otherwise, the precompiled header will be ignored and the source file will be compiled in the
normal manner.  Please see the [userguide](userguide/nativeBinaries.html#native_binaries:preCompiledHeaders) for further information.

### Google Test support (i)

- TBD

## Promoted features

Promoted features are features that were incubating in previous versions of Gradle but are now supported and subject to backwards compatibility.
See the User guide section on the “[Feature Lifecycle](userguide/feature_lifecycle.html)” for more information.

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

<!--
### Example promoted
-->

## Fixed issues

## Deprecations

Features that have become superseded or irrelevant due to the natural evolution of Gradle become *deprecated*, and scheduled to be removed
in the next major Gradle version (Gradle 3.0). See the User guide section on the “[Feature Lifecycle](userguide/feature_lifecycle.html)” for more information.

The following are the newly deprecated items in this Gradle release. If you have concerns about a deprecation, please raise it via the [Gradle Forums](http://discuss.gradle.org).

### Changing a configuration after it has been resolved

TODO

## Potential breaking changes

### Distribution Plugin changes

Due to a bug in the distribution plugin (see GRADLE-3278), earlier Gradle versions didn't follow the general naming convention for the assemble task of the main distribution.
This has been fixed and assemble task name for the main distribution has changed from `assembleMainDist` to `assembleDist`.

### Removal of `componentSpec` project extension

As part of work on exposing more of the component model to rules the `componentSpec` project extension previously added by all language plugins via `ComponentModelBasePlugin` has been removed.
Currently component container can be only accessed using model rules.

### `model.components` cannot be viewed as

### Configurations that are task inputs are resolved before building the task execution graph

## External contributions

We would like to thank the following community members for making contributions to this release of Gradle.

* [<NAME>](https://github.com/Shad0w1nk) - Support GoogleTest for testing C++ binaries
* [<NAME>](https://github.com/lptr), [<NAME>](https://github.com/vigoo) and [<NAME>](https://github.com/vujevits) - implement dependency substitution for projects

## Known issues

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

{'fraction_non_alphanumeric': 0.07157373862331007, 'fraction_numerical': 0.0019439780860652117, 'mean_word_length': 3.5673930589184826, 'pattern_counts': {'":': 6, '<': 18, '<?xml version=': 0, '>': 28, 'https://': 11, 'lorem ipsum': 0, 'www.': 0, 'xml': 0}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 0, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
{'dir': 'git-commits-cleaned', 'id': '5990038', 'n_tokens_mistral': 2754, 'n_tokens_neox': 2597, 'n_words': 1258}