The Feature Lifecycle
Gradle is under constant development and improvement. New versions are delivered on a regular and frequent basis (approximately every 6 weeks) as described in the section on end-of-life support. Continuous improvement combined with frequent delivery allows new features to be made available to users early and for invaluable real world feedback to be incorporated into the development process. Getting new functionality into the hands of users regularly is a core value of the Gradle platform. At the same time, API and feature stability is taken very seriously and is also considered a core value of the Gradle platform. This is something that is engineered into the development process by design choices and automated testing, and is formalised by the section on backwards compatibility.
The Gradle feature lifecycle has been designed to meet these goals. It also serves to clearly communicate to users of Gradle what the state of a feature is. The term feature typically means an API or DSL method or property in this context, but it is not restricted to this definition. Command line arguments and modes of execution (e.g. the Build Daemon) are two examples of other kinds of features.
Features can be in one of 4 states:
Internal features are not designed for public use and are only intended to be used by Gradle itself. They can change in any way at any point in time without any notice. Therefore, we recommend avoiding the use of such features. Internal features are not documented. If it appears in this User Manual, the DSL Reference or the API Reference documentation then the feature is not internal.
Internal features may evolve into public features.
Features are introduced in the incubating state to allow real world feedback to be incorporated into the feature before it is made public and locked down to provide backwards compatibility. It also gives users who are willing to accept potential future changes early access to the feature so they can put it into use immediately.
A feature in an incubating state may change in future Gradle versions until it is no longer incubating. Changes to incubating features for a Gradle release will be highlighted in the release notes for that release. The incubation period for new features varies depending on the scope, complexity and nature of the feature.
Features in incubation are clearly indicated to be so. In the source code, all methods/properties/classes that are incubating are annotated with Incubating, which is also used to specially mark them in the DSL and API references. If an incubating feature is discussed in this User Manual, it will be explicitly said to be in the incubating state.
Feature Preview API
The feature preview API allows certain incubating features to be activated by adding
enableFeaturePreview('FEATURE') in your settings file. Individual preview features will be announced in release notes.
When incubating features are either promoted to public or removed, the feature preview flags for them become obsolete, have no effect and should be removed from the settings file.
The default state for a non-internal feature is public. Anything that is documented in the User Manual, DSL Reference or API references that is not explicitly said to be incubating or deprecated is considered public. Features are said to be promoted from an incubating state to public. The release notes for each release indicate which previously incubating features are being promoted by the release.
A public feature will never be removed or intentionally changed without undergoing deprecation. All public features are subject to the backwards compatibility policy.
Some features will become superseded or irrelevant due to the natural evolution of Gradle. Such features will eventually be removed from Gradle after being deprecated. A deprecated feature will never be changed, until it is finally removed according to the backwards compatibility policy.
Deprecated features are clearly indicated to be so. In the source code, all methods/properties/classes that are deprecated are annotated with “
@java.lang.Deprecated” which is reflected in the DSL and API references. In most cases, there is a replacement for the deprecated element, and this will be described in the documentation. Using a deprecated feature will also result in a runtime warning in Gradle’s output.
Use of deprecated features should be avoided. The release notes for each release indicate any features that are being deprecated by the release.
Backwards Compatibility Policy
Gradle provides backwards compatibility across major versions (e.g.
2.x, etc.). Once a public feature is introduced or promoted in a Gradle release it will remain indefinitely or until it is deprecated. Once deprecated, it may be removed in the next major release. Deprecated features may be supported across major releases, but this is not guaranteed.
Release end-of-life Policy
Every day, a new nightly build of Gradle is created. This contains all of the changes that have made it through Gradle’s extensive continuous integration tests during that day. Not every nightly may contain new changes and not every nightly may be stable.
For each minor or major release, the Gradle team creates a pre-release distribution called a release candidate (RC). When no problems are found after a short period of time (usually a week), the release candidate is promoted to a final/general availability (GA) release. If a regression is found in the release candidate, a new RC distribution is created and the process repeats. Release candidates are supported for as long as the release window is open, but they are not intended to be used long term for production use. Bug reports are greatly appreciated during the RC phase.
After a final release, the Gradle team may create additional patch releases that are intended to replace the previous final release due to an important bugfix or regression. For instance, Gradle 5.2.1 replaces the Gradle 5.2 release. Once a release candidate has been made, all feature development moves on to the next release for the most recent major version. As such, each minor Gradle release causes the previous minor releases in the same major version to become end-of-life (EOL), and these releases will not receive any new bugfixes or feature backports.
For major versions, Gradle will backport critical fixes and security fixes to the last minor in the previous major version. For example, while Gradle 7 was the latest version, there were several releases in the 6.x line: the 6.9 and subsequent releases.
As such, each major Gradle release causes:
The previous major version becomes maintenance only and it will only receive critical bug fixes and security fixes.
The major version before the previous one to become end-of-life (EOL), and that release line will not receive any new fixes.