You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In my client's project, we execute the releaseUpdateVersion task provided by the ResearchGate gradle-release plugin before we execute the publish task from your plugin. (There's some history for doing it in this order that I won't bore you with.) The releaseUpdateVersion task bumps the version number in gradle.properties so the next build uses that version number.
It may be significant to this issue scenario that both tasks are executed in the same Gradle command; i.e. gradlew releaseUpdateVersion publish.
In Gradle 3.5.1, this ordering worked fine. The published artifact had the version number initially read by Gradle from gradle.properties when Gradle command executed.
After upgrading to Gradle 4.10.3, this same ordering no longer works and the publish task publishes an artifact using the newly updated version number.
In reviewing Gradle debug output from the build job, it's not obvious what drove the changed behavior. I'm suspicious Gradle 4 is caching a mutable version number that the releaseUpdateVersion caused to be mutated, but I'm just not sure.
Ours is likely an unorthodox scenario where the next version number is set before the publish is done, but I thought I'd mention it here in case someone else bumps into this.
The text was updated successfully, but these errors were encountered:
Since Gradle does not guarantee task ordering depending on what tasks are written, but instead guarantees they are executed in the order of their dependencies, I suspect that you'll want to add a link/ dependsOn to ensure the order of tasks that you're looking for.
This is more an FYI than a bug report.
In my client's project, we execute the
releaseUpdateVersion
task provided by the ResearchGate gradle-release plugin before we execute thepublish
task from your plugin. (There's some history for doing it in this order that I won't bore you with.) ThereleaseUpdateVersion
task bumps theversion
number in gradle.properties so the next build uses that version number.It may be significant to this issue scenario that both tasks are executed in the same Gradle command; i.e.
gradlew releaseUpdateVersion publish
.In Gradle 3.5.1, this ordering worked fine. The published artifact had the
version
number initially read by Gradle from gradle.properties when Gradle command executed.After upgrading to Gradle 4.10.3, this same ordering no longer works and the
publish
task publishes an artifact using the newly updated version number.In reviewing Gradle debug output from the build job, it's not obvious what drove the changed behavior. I'm suspicious Gradle 4 is caching a mutable version number that the
releaseUpdateVersion
caused to be mutated, but I'm just not sure.Ours is likely an unorthodox scenario where the next version number is set before the publish is done, but I thought I'd mention it here in case someone else bumps into this.
The text was updated successfully, but these errors were encountered: