Provide a configurable way to manipulate the module version

[klu2]

We should - like in the old cloudflight-gradle-plugin - provide the possibility to manipulate the current version of a build.

In the old plugin, bound to TeamCity, we are using code like that:

class BuildUtils {

    private static final String VERSION_SUFFIX_SNAPSHOT = '-SNAPSHOT'
    private static final String VERSION_SUFFIX_BUILD_COUNTER = '-b'

    private static final Logger BUILD_LOG = Logging.getLogger 'io.cloudflight.gradle.build'

    static void deduceBuildProperties(Project project) {
        if (isTeamcityBuild(project)) {
            def configuration = new Properties()
            configuration.load(new FileReader(project.teamcity['teamcity.configuration.properties.file'] as String))

            if (EnvironmentUtils.isVerifyBuild()) {
                // gitlab auto-merge feature requires version number to equal git-hash
                project.version = configuration.getProperty('build.vcs.number')
            } else if (!EnvironmentUtils.isPublishBuild()) {
                // teamcity-shared library also allows to call the publish task on the master build, in that case we set the env parameter
                // PUBLISH_BUILD to false there and then we do want to publish -SNAPSHOT versions to our repository on successful master builds

                if (appendBuildCounterOnDefaultBuild()) {
                    project.version += VERSION_SUFFIX_BUILD_COUNTER + configuration.getProperty("build.counter")
                } else {
                    // add git -SNAPSHOT to version number
                    project.version += VERSION_SUFFIX_SNAPSHOT
                }
            }

            TeamCityUtils.setBuildNumber(project.version as String)

        } else if (!EnvironmentUtils.isPublishBuild() && !EnvironmentUtils.isVerifyBuild()) {
            // only use snapshot versions locally
            project.version += VERSION_SUFFIX_SNAPSHOT
        }

        // copy group and build version to all modules
        for (def child : project.allprojects) {
            child.group = project.group
            child.version = project.version
        }
    }
}

The version number is therefore being adapted directly from the Gradle-Plugin, and is being enriched with data from the CI-Server

In contrary, in this repository here (autoconfigure-gradle-plugin) we are using a very simplified form:

if (System.getenv("RELEASE") != "true") {
    version = "$version-SNAPSHOT"
}

The version for release builds is being injected by the CI-Server (Github Actions) in that case.

What we should do is to provide some kind of strategy interface to the autoconfigure-gradle-plugin which takes care about that, and which can also be configured/extended from outside. The default could be the version we are using here inside this plugin (just appending the -SNAPSHOT suffix for local builds)

What we could do in any case is to propagate the build number of the root module to all other modules:

        // copy group and build version to all modules
        for (def child : project.allprojects) {
            child.group = project.group
            child.version = project.version
        }

[klu2]

We should probably also consider https://blog.dipien.com/automatic-semantic-versioning-on-your-gradle-project-6343b626b27b

[klu2]

Or https://github.com/ajoberstar/reckon

[klu2]

I tried https://github.com/ajoberstar/reckon at https://github.com/cloudflightio/json-wrapper and looks really promising:

• Add the plugin as settings-plugin: https://github.com/cloudflightio/json-wrapper/blob/0.5.1/settings.gradle.kts
• Remove the version from build.gradle: https://github.com/cloudflightio/json-wrapper/blob/0.5.1/build.gradle.kts
• Adapt github-publish.yml: https://github.com/cloudflightio/json-wrapper/blob/0.5.1/.github/workflows/github-publish.yml

The workflow now is not to create a release any more via the Github pages and manually enter the release number, but instead you go to the actions, select the "Publish package to the Maven Central Repository" workflow and then you are prompted the following dialog:

If we are currently running on 0.5.0-SNAPSHOT and the last release was 0.4.5, then depending on your selection of the scope, your new version will be:

• patch: 0.4.6
• minor: 0.5.0
• major: 1.0.0

No need to manually adjust any versions, just as mentioned in https://github.com/ajoberstar/reckon

The tag is being created by the reckon plugin in this line.

After that you can/should create the release-page under https://github.com/cloudflightio/json-wrapper/releases and the select the already created tag, and add the changelog there.

[klu2]

Intersting is also the new ReckonSettingsPlugin which implements Plugin<Settings> and can therefore perform code before the real project-based plugins are being executed. See https://github.com/ajoberstar/reckon/releases/tag/0.17.0-beta.4 and ajoberstar/reckon#147 for insights.

In case we would embed this plugin into ours we would most likely need to somehow reuse that concept, i.e. provide our own Settings plugin in addition to what we have already.