Do you all produce a listing of “recommended” or “supported” versions of Gradle? We’ve been using Gradle for quite some time now, but we’re starting to see version fragmentation across our teams. I met recently with some of our enterprise build team members to discuss this issue and devise a way to mark older versions “end of life” to keep everyone up with the times. We came up with the following support schedule for our internal build system and were curious if you all had better recommendations? We figured at a minimum we should support any version officially recommended by the people who make it.
Our version support list:
Latest minor build of the two most recent major versions (e.g. 2.14 and 3.1, but NOT 1.12)
The five most recent minor builds (e.g. 3.1, 3.0, 2.14, 2.13, 2.12)
Any patched version of the above builds (e.g. 2.14.1)
That would give us the following list of supported versions (as of Oct 7):
3.1, 3.0, 2.14.1, 2.14, 2.13, 2.12
And as Gradle continues to evolve beyond 3.5, the following list (version 3.0 phased out in favor of newer minor versions):
3.5, 3.4, 3.3, 3.2, 3.1, 2.14.1, 2.14
Hopefully this generally aligns with your development model with regards to breaking changes, or seismic shifts in implementation.
if you can you should of course try to move your teams quickly along Gradle releases, e.g. only support the last three or so. This minimizes fragmentation and all teams benefit from the latest performance enhancements.
If this is not possible, then your current plan makes sense with a minor change: You should never use versions if there was a patch for it. So don’t use 2.14, only use 2.14.1
That’s a good point about the patched version, I’ll be sure to update that. Most of the other decisions were driven by the fact that a lot of teams don’t have dedicated build masters, so upgrading builds every couple of months would probably get on peoples nerves. Especially when upgrading to a new major version there could be a lot of issues.
It really depends, we spend a lot of time on backwards compatibility. Even major updates are drop-in replacements for many users. Problems usually occur when you use internal or deprecated APIs. The longer you hold back the more painful an update could get. You could even automate it: Check out all projects, update Gradle to latest version, see if it still builds, check back in (or notify the team that it is time to upgrade).
