Currently if I want to update the wrapper for a new Gradle distribution, I either do change gradleVersion in the Wrapper task and execute it two times, first time to update the gradle-wrapper.properties with the new Gradle version and second time to actually update the Wrapper from the new Gradle version, or I do change the gradleVersion in the Wrapper task, change the distributionUrl in the gradle-wrapper.properties and then execute the Wrapper task to update the Wrapper from the new Gradel version.
Do I miss something on how to do it in one step? I’d like to only change the gradleVersion in the Wrapper task and then execute the Wrapper task one time to get the updated wrapper. If this is not possible currently, could this maybe be added / changed, so that the wrapper is always generated from the gradle version specified in the Wrapper task?
Currently you need to execute the wrapper first time to change the gradle version you use to do the builds and the second time to update the gradle/wrapper/gradle-wrapper.jar (this second step is not always necessary. You need to do it only to get new features implemented in the wrapper).
The normal use case is to run the wrapper task once.
Rarely depends on the definition. As far as I can see from the source (I looked as cli and wrapper subprojects, if more are involved, maybe even more often), the wrapper was updated in 1.0, 1.2 and 1.6.
So you more or less always have to read the detailed release notes and keep in mind looking for something mentioning a wrapper update, hoping that an update would be mentioned.
As recopying the wrapper even if it didn’t change shouldn’t do any harm, I’d tend to think that it is more safe and reliable to always recopy it if you call the wrapper task, from the target version of the wrapper task just as I suggested. This way you always have a matching wrapper, suitable to the Gradle version you are using and you do not miss an update to the wrapper, no matter whether it is because it was not mentioned in the release notes or you simply didn’t read them. I e. g. more fly over release notes but then diff the userguide of the old and new version to see what has changed.
