Open benignbala opened 8 years ago
Problem is that Gradle, AFAIK, doesn't enforce setting the wrapper version to the current Gradle version, so what happened was that the wrapper was usually several versions behind the Gradle version we used to build the binaries. In the end we decided not to bother with maintaining it as the vast majority of users use the binaries, those who want to build can download Gradle, and the wrapper doesn't enforce the same Gradle version anyway.
We author quite a few open-source projects, and we don't even enforce the same Gradle versions amongst ourselves (using the wrapper for our own builds is just wasteful) and so the wrapper is just one more thing to maintain with little benefit. So far, though, we have yet to encounter any issues resulting from using different Gradle versions.
@pron
Gradle wrapper is the recommended practice for any Gradle project. Also, services like JitPack might use outdated Gradle version as default one. Right now I can't build the project because it's not buildable with Gradle 2.8 (which is the default if no wrapper is presented): https://jitpack.io/com/github/puniverse/quasar/v0.7.5/build.log
As you said:
we have yet to encounter any issues resulting from using different Gradle versions
It means that you can add a wrapper, but don't bother maintaining it until it's too outdated to build the project. But it'll help others to follow the standard Gradle way. In fact, I don't have a gradle
at my PATH at all because all my projects are wrapped.
Plus...
Problem is that Gradle, AFAIK, doesn't enforce setting the wrapper version to the current Gradle version
This is not a problem, this is a feature, actually. "Always the latest" is known bad way for the software dependency management :)
It is always recommended to have a gradle wrapper script so that all of us use the same version of gradle to build the project.