The first Gradle 1.12 release candidate will be released in the next few days. It is the last intended release of the Gradle 1.x line.
In 8 or so weeks, we will be releasing Gradle 2.0.
Since releasing Gradle 1.0 on June 6th 2012, we’ve released 12 subsequent significant updates at an average of a new release every 8 weeks. We’ve also maintained an extremely high degree of backwards compatibility. The vast majority of builds written for Gradle 1.0 work without modification when run with Gradle 1.12. This is not by accident. When fixing bugs, improving features and even adding new features, the Gradle development team frequently makes compromises in order to maintain backwards compatibility. This allows us to get new features, fixes and improvements into your hands faster without a heavy upgrade cost. Gradle helps teams around the world continuously deliver software and we work hard to continuously deliver Gradle itself to those teams.
The change in major version number from 1 to 2 for all future Gradle releases is a technical signal that we are setting a new compatibility baseline. On the 1.x journey, we have deprecated features that are no longer useful and/or have been superseded. Gradle 2.0 will drop many of these deprecated features, but not all.
The version move does not change the incubating feature policy. Some of the incubating feature set will be promoted to stable for the 2.0 release, and the rest will continue to evolve as the particular feature demands. In short, it’s business as usual with regard to feature incubation.
If your build works with Gradle 1.12 and does not issue any deprecation warnings while building, it is extremely likely that your build will continue to work just fine with Gradle 2.0 and continue to work until Gradle 3.0. Only features that have been formally marked as deprecated will be removed, and typically only those features that have been deprecated for at least two releases of Gradle. The majority of builds will either just work with Gradle 2.0 or require a small amount of work to replace use of features that were removed.
One significant change that is coming in Gradle 2.0 is the upgrade to Groovy 2. This should not cause compatibility issues for the vast majority of users, but it is a significant change. This change primarily concerns plugins as they are compiled with and against the version of Groovy that Gradle provides. Groovy 2 is for the most part binary and API compatible with Groovy 1.8.x. However, some exotic uses of Groovy may not be compatible. Some plugins may need to be rebuilt with Gradle 2.0 in order to work in Gradle 2.0 builds. Most plugins will just continue to work fine as is.
The move to Gradle 2.0 allows a lot of legacy “weight” to be jettisoned from Gradle, making the development of future features easier and faster. The “2.0” version move is a technical signal and not a marketing one. You can expect regular delivery of new features for the 2.x line, in the same non disruptive way that they were delivered for 1.x. We are serious about our commitment to stability and making it easy for users to “stay current” in their Gradle usage.
We would like to strongly encourage you to try out the release candidates of Gradle 2.0 when they become available and give us your feedback. We put Gradle through rigorous testing after every commit, but the feedback we get from real world testing is extremely valuable. By testing out the Gradle 2.0 release candidates on your build and letting us know of any problems, you will make it easier to upgrade your projects to Gradle 2.0 final.
If you’re wondering what features are in store for Gradle 2.0 and beyond, more information will be forthcoming closer to the release. You can also get the information direct from the source at the Gradle Summit in Santa Clara on June 12th and 13th.
The entire Gradle development team will be there to chat with and to present sessions on various different Gradle topics, including the future roadmap and direction of the Gradle platform. Space is limited. Get your ticket now.
Lastly, thank you to you for being part of the Gradle 1.x story. The feedback, plugins and code contributions provided by the Gradle community goes a long way to making Gradle what it is today. We hope you’ll continue to be part of the community and be a part of this new era in the evolution of Gradle.