Release process so that no flag toggling occurs

[soloturn]

the last release of sonarqube introduced a message showing up unmotivated in build logs. for projects who just continuously upgrade to newest versions the choice you opted for is a little unlucky. it forcea people set a flag for one release, and remove it again a release later as it became then default.

can you please just change the default behaviour and provide a flag to revert to old, in case?

the relevant message is:
The ‘sonarqube’ task depends on compile tasks. This behavior is now deprecated and will be removed in version 5.x. To avoid implicit compilation, set property ‘sonar.gradle.skipCompile’ to ‘true’ and make sure your project is compiled, before analysis has started.
The ‘sonar’ task depends on compile tasks. This behavior is now deprecated and will be removed in version 5.x. To avoid implicit compilation, set property ‘sonar.gradle.skipCompile’ to ‘true’ and make sure your project is compiled, before analysis has started.

[Colin]

Hey there.

Thanks for the feedback.

@soloturn

can you please just change the default behaviour and provide a flag to revert to old, in case?

Doing so would be a breaking change for a lot of users, which is why we needed to introduce this gradually.

You can read more about the change here:

SonarScanner for Gradle: you can now decide when to compile

Hello, We made a change in the SonarScanner for Gradle so you can control when your code is compiled. Until today, the SonarScanner for Gradle was behaving like this: when you were running gradle sonar, under the hood, it was triggering/forcing the compilation this was a hard dependency and it was not possible to deactivate it We made this design choice years ago because, for Java and Kotlin code, the Sonar analyzers must have access to the bytecode to perform an accurate analysis. So forci…

[soloturn]

we have maybe a different opinion what is a breaking change or not. changing behaviour in a major relase is a breakting change. but - where is the problem? you properly documented why you do so and all is fine.

but printing a pointless warning message in a minor release bEFORE that major release is a breaking change - because THAT one really fills up log files, and did come out of the blue. and you do NOT release your new version so this warning message goes away finally. oh my god