Siarhei Krukau

@tbroyer, yep, looks exactly what I was talking about! And, yeah, updates are almost impossible with this approach.

I think something like this would be better for Kotlin birthday, than the one I've added as an example: 

https://blog.jetbrains.com/kotlin/2021/05/10-years-of-kotlin-stories/ >On July 19, 2011, at the JVM Language Summit, JetBrains announced Kotlin – a new statically typed programming language for the JVM. So, it has been here for almost...

How about this one?  :)

Faced the same issue. Even ``` groovy release { buildTasks = [''] // buildTasks = ['subproject:build'] } ``` does not help

No, that doesn't help. I connected to the Gradle in debug and it looks like it first runs build with `['build']` and then with whatever I set in `release.buildTasks`. Maybe...

Yes. When I run `./gradlew build` from the root (`A`) it builds both projects.

When I put release configuration in subprojects: ``` groovy plugins { id 'java' id 'net.researchgate.release' version '2.3.2' } release { versionPropertyFile = '../gradle.properties' } ``` The build fails because first...

And the final blocker. Even if I use separate `gradle.properties` for both subprojects and configure them independently, I get snapshot checking exception because second subproject (`A2`) depends on first (`A1`)....

I've created a demo: https://github.com/madhead/gradle-release-demo: ``` ┌[madhead@madhead-linux:~/Projects/gradle-release-demo] └─$ ./gradlew release -Prelease.useAutomaticVersion=true :release :gradle-release-demo:createScmAdapter :gradle-release-demo:initScmAdapter :gradle-release-demo:checkCommitNeeded :gradle-release-demo:checkUpdateNeeded :gradle-release-demo:unSnapshotVersion :gradle-release-demo:confirmReleaseVersion :gradle-release-demo:checkSnapshotDependencies :gradle-release-demo:runBuildTasks FAILED :release FAILED Release process failed, reverting back any changes...