The Gradle Release Approach

(Hans Dockter) #1

Release Frequency

1.0 had been a long time in coming, but we have reason to be very satisfied with our track record for releases in the last 6 months. We had milestone releases every 6 weeks, the first RC for 1.1 was out 6 weeks after the 1.0 release. In general we intend to have new RC’s for our minor releases 4 weeks after the last minor release. This provides us with a constant stream of early feedback from the community and provides you with the benefit of new features and fixes at lower latency. Work in progress is, after all, waste!

For the Gradle developer this is also a very efficient way of spending their scarce resources. Unless a bug is absolutely critical the fix will come with the next release. We don’t need to deal with merges as all the work is done in the master branch. This is what we consider as continuous delivery best practices and what we have also practiced with the milestone releases.

Backwards Compatibility and new Features

Beginning in the last couple of milestone releases, we began to place extreme priority on backward compatibility. We have a clear framework in place to support this:

  • A strong suite of automated backwards compatibility tests * A commitment to precede every minor release with an RC phase * A forthcoming Upgrade and Migration Plugin (Gradle 1.2) that will allow you to compare builds done with different versions of Gradle (we’re really excited about how powerful this is going to be)

We are overflowing with new and innovative ideas for Gradle, and we will roll some of them out with every minor release.

We will typically introduce big new features as experimental at first, giving you a chance to test them out as you have opportunity. We will iterate on the new feature based on your feedback, eventually releasing it as stable and production-ready. (Those of you who use features before that point gain the competitive advantage of early access to new functionality in exchange for helping refine it over time.) When a functionality upgrade becomes production-ready, we might choose to mark the old feature as deprecated. We probably won’t keep deprecated features around as long as the JDK does, but you can rest assured that you’ll have plenty of time to migrate from old deprecated features to their replacement. All upcoming minor releases will support deprecated features, and in some circumstances, major releases may as well. However, we will garbage-collect deprecated features at some point to reduce the complexity of the Gradle code base and flatten out its learning curve for new users. We will always work to reduce the entropy in the product.

Design Docs We have started to write design docs for the most important new features we are planning to implement soon but also for the important processes of the Gradle project itself. Those design docs can be found in the Gradle Git repository.

In regard to this posting, two design docs are of particular interest: - The backwards compatibility process - The upcoming build migration plugin