dipien/semantic-version-gradle-plugin

Gradle Plugin to automatically use Semantic Versioning on your Gradle project

semantic-version-gradle-plugin's Issues

Support configuration cache?

We're currently using https://github.com/ethauvin/semver-gradle as it seems undermaintained.

Hope for the dipien/semantic-version-gradle-plugin support for configuration cache(?)

The 'samples/apply-on-subproject-sample' do not work

Describe the bug

The multi-project setup does not seem to work according to the provided sample.

To Reproduce
When cloning this repository and running:

cd semantic-version-gradle-plugin/samples/apply-on-subproject-sample
./gradlew build

... the following error appears:

(some output omitted here)
* What went wrong:
A problem occurred evaluating project ':child1'.
> Failed to apply plugin 'com.dipien.semantic-version'.
   > The Semantic Version Gradle plugin must be applied only on the root project
(some output omitted here)

Expected behavior
Based on the multi-module setup, it should be possible to increase sub-project version (I'd assume as there's the sample available).

Android Gradle plugin not assigning the correct version classifier

Describe the bug
I applied the plugin with Android support.

dependencies {
    classpath "com.dipien:semantic-version-android-gradle-plugin:1.4.1"
}

version = "1.0.0"
apply plugin: "com.dipien.android.semantic-version"

I do not want the -SNAPSHOT version classifier in my build version name, so I declared the following extension.

semanticVersion {
    snapshot = false
}

However, the -SNAPSHOT version classifier is still being applied. I tried other properties such as alpha, beta and versionClassifier itself, but I could not successfully apply any of them.

To Reproduce
Steps to reproduce the behavior:

1. Apply plugin for Android support
2. Set snapshot property to false
3. Build Android project
4. Check VERSION_NAME in the generated BuildConfig.java file

Expected behavior
Version classifier should be applied according to the properties set in the extension.

Screenshots

Additional context
Although I have not tested the code locally, I thought that the following code lines might be the ones causing the issue.

semantic-version-gradle-plugin/semantic-version-android-gradle-plugin/src/main/java/com/semanticversion/android/gradle/plugin/SemanticVersionAndroidGradlePlugin.kt

Lines 47 to 48 in 92f6b30

	androidAppExtension.defaultConfig.versionCode = AndroidVersion(baseVersion, config).versionCode
	androidAppExtension.defaultConfig.versionName = project.version.toString()

Although versionCode is created with config, the creation of versionName does not take config into account.

By the way, I tried setting the Android-specific property in the extension, and it worked. The base properties such as snapshot, alpha, beta etc. do not.

semanticVersion {
    minSdkVersionAsVersionCodePrefix = true
}

Fail the build when versionCode or versionName are explicitly defined on android.defaultConfig

Feature branch support

Enabling independent version management for subprojects

Hi guys,

I'm currently working in a project where is required to implement automatic semantic versioning into some specific projects. These projects are in a single repository but it is required to have independent versions even if everybody can push to the same repo for different projects.

Describe the solution you'd like
Is there a way to implement the plugin but keeping independent version bumping between subprojects? It'will be great to tag versions (prereleases and releases) with custom suffix to keep track of the version changes per project.

I'm gonna try to fork the plugin and implement something by my self. I'll keep you guys updated in case that something good happens, but if you have any insight on how to use this plugin in something similar to what I'm looking also will be great.

Thanks a lot

LOCAL classifier support

Add flag to avoid failure with configuration cache

Add notCompatibleWithConfigurationCache flag to avoid failure with configuration cache

Support Gradle Configuration Cache

https://docs.gradle.org/current/userguide/configuration_cache.html#config_cache:intro

Modifdy the app `build.gradle` `defaultConfig` section

Hello there 👋

First of all, thanks for your work. Now, without further ado, let's get to the point.

Is your feature request related to a problem? Please describe.
I have a very simple Android application, and I'd like to be able to increment the versionCode and versionName which are described within the app build.gradle file.
The printVersion command gives me the output I'm looking for:

Version: 1.0.1
Version code: 100
Version name: 1.0.1

Calling the incrementVersion changes the value of version in the main build.gradle, but not in the app/build.gradle in the defaultConfig section.

Describe the solution you'd like
I would like the versionCode and versionName to be incremented in the defaultConfig section of the app/build.gradle file.

Describe alternatives you've considered
A clear and concise description of any alternative solutions or features you've considered.

Additional context
Thank you.

Suport for commit message prefix

When using Conventional Commit checks in GitHub workflow actions, they always fail because this plugin generates commits that are not compliant.

It would be nice if the commit message prefix could be customised.

maximumVersion parameter isn't working

An attempt to set a maximumVersion over default 99 value don't work and leads to error or unexpected behavior depending on specific case.

Unexpected behavior case:

1. In root build.gradle set ext.maximumVersion="999" and version = "1.0.99"
2. Run ./gradlew incrementVersion --versionIncrementType=PATCH
3. See version = "1.1.0" in root build.gradle instead version = "1.0.100"

Error case:

1. In root build.gradle set ext.maximumVersion="999" and version = "1.0.100"
2. Run ./gradlew refresh
3. See error:

• What went wrong:
  A problem occurred evaluating root project 'new-project'.
  Failed to apply plugin 'com.dipien.semantic-version'.
  The version patch [100] should be a number between 0 and 99

After digging into source code I found that the reason might be in using constructor(version: String) of Version (which does not allow to override maximumVersion, but contain validation of baseVersion) in SemanticVersionGradlePlugin apply()-method and in IncrementVersionHelper increment()-method.

Print version task

Remove some properties on extensions

The following properties can't be defined on the semanticVersion extension anymore:

• maximumVersion
• versionClassifier
• snapshot
• beta
• alpha

Reason: the plugin need to use them before the semanticVersion extension is created.
You can still define them as gradle properties.

Failed to apply plugin due to missing project version, when there is one in build.gradle.kts

Describe the bug
After adding the plugin to the "plugins" block section and running the configure task "prepareKotlinBuildScriptModel", the
semantic-version-gradle-plugin fails during the apply phase due to a missing project version that is actually in place.

To Reproduce
Steps to reproduce the behavior:

1. Have a springboot 3.0.1 project with gradle 7.6 and a Kotlin-based build.gradle.kts
2. Add "version" to build.gradle.kts
3. Add "com.dipien.semantic-version" (version 2.0.0) to the plugins block section
4. Run configure task "prepareKotlinBuildScriptModel"
5. See error

Expected behavior
It should detect the project's version so the plugin can be successfully applied

Screenshots

Additional context
I suspected it would be caused by a race condition of not having the project object created during the "Add/Apply Plugins" section, and added the workaround on not applying the plugin until the task "prepareKotlinBuildScriptModel" is done and it seems to be working perfectly fine after that:

Nevertheless, this workaround should not be needed.

Version in gradle.properties

Is your feature request related to a problem? Please describe.
As a developer, I store version values in the gradle.properties file. and it can't be updated

Describe the solution you'd like
I would like that gradle.properties is updated

Describe alternatives you've considered
no alternatives

Additional context
we use gradle.properties for changes

Support for different maximum versions for major, minor and patch

Fail when version is not defined in root project

Semantic version support

Support for RC version classifier

Increment version task