This issue is not about the actual plugin that should be fixed, but about the warnings you get from Gradle.

Current situation

If you have a build.gradle containing only the following

plugins {
    id 'net.vivin.gradle-semantic-build-versioning' version '2.0.1'
}

you get a little helpful message saying

The Task.leftShift(Closure) method has been deprecated and is scheduled to be removed in Gradle 5.0. Please use Task.doLast(Action) instead.

This does not help in identifying where the issue comes from, especially as the error is not in your own stuff, but only in something you used.

If you use the old syntax like

buildscript {
    repositories {
        maven {
            url "https://plugins.gradle.org/m2/"
        }
    }
    dependencies {
        classpath 'gradle.plugin.net.vivin:gradle-semantic-build-versioning:2.0.1'
    }
}
apply plugin: 'net.vivin.gradle-semantic-build-versioning'

the message you get is a little bit more helpful message saying

The Task.leftShift(Closure) method has been deprecated and is scheduled to be removed in Gradle 5.0. Please use Task.doLast(Action) instead.
        at build_6g2ab18mlnmu6rgghgkr1aj2l.run(/path/to/build.gradle:11)

So in this case you at least know what 3rd party thing the warning comes from.

If the whole thing is a settings plugin (incidentally the plugin I use in the examples is transformed to a settings plugin in the current master branch), you are back to the original message. Having an empty build.gradle and in the settings.gradle file the following:

rootProject.name = 'test'

buildscript {
    repositories {
        mavenLocal()
        mavenCentral()
    }
    dependencies {
        classpath 'net.vivin:gradle-semantic-build-versioning:2.0.3-SNAPSHOT'
    }
}

apply plugin: 'net.vivin.gradle-semantic-build-versioning'

you get a message again saying

The Task.leftShift(Closure) method has been deprecated and is scheduled to be removed in Gradle 5.0. Please use Task.doLast(Action) instead.

without any indication where the warning comes from.

Problems / Suggestions

• If a deprecation warning comes from something 3rd party, log the 3rd party thing it comes from, not the line where it is used or no location info at all, so you can report to the 3rd party, or upgrade the thing you use.
• If the deprecation warning was only for something 3rd party, don't warn about the same deprecation issue in the same 3rd party again, but warn about a different 3rd party or own violation, so you can report against all 3rd parties and fix your own code at the same time. Otherwise you have to report against the first 3rd party, wait until they fixed all those issues, then report against the next 3td party until they fixed all those issues, ..., then you can start to fix your own issues. The whole things gets even worse if you use your own plugin in your own build, because then you have a hen-and-egg problem. To see the issues in your own code, you would have to fix the issues in your own plugin first, but you don't see the issues in your own plugin, because the plugin you use (your own plugin) shades the issues in your own plugin. Pretty nasty recursive hen-and-egg problem.
• Extend TestKit to be able to tell GradleRunner to fail the build if there are any deprecation warnings. I would even make this behavior the default, but off-turnable.