Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Small issue after upgrading to Gradle 4.10.3 from 3.5.1 #152

Open
jfrosch opened this issue Oct 18, 2019 · 1 comment
Open

Small issue after upgrading to Gradle 4.10.3 from 3.5.1 #152

jfrosch opened this issue Oct 18, 2019 · 1 comment

Comments

@jfrosch
Copy link

jfrosch commented Oct 18, 2019

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 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.

@OdysseusLives
Copy link
Member

Hello, thanks for sharing!

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants