vivin / gradle-semantic-build-versioning

Gradle plugin to generate version-numbers and tags using semantic versioning
MIT License
85 stars 32 forks source link

promote-to-release is not working #80

Closed Pralhadb closed 7 years ago

Pralhadb commented 7 years ago

Hi,

I did the required changes suggested by you and have implemented the plugin successfully. It is working fine with Major, Minor and Patch version. But, I am facing issues while promoting the version from pre-release. It is giving error with "promote-to-release" commit. Could you please help me out with this.

Pralhadb commented 7 years ago

In setting.gradle, I did:

buildscript{ repositories { maven { } }

}
dependencies{
    classpath 'gradle.plugin.net.vivin:gradle-semantic-build-versioning:3.0.4'
}

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


also, added: semantic-build-versioning.gradle which conteins:

Pralhadb commented 7 years ago

also, added: semantic-build-versioning.gradle which conteins:

autobump {

majorPattern = ~/(?m)^\[bump-major\]$/
minorPattern = ~/(?m)^\[bump-minor\]$/
patchPattern = ~/(?m)^\[bump-patch\]$/
newPreReleasePattern = ~/(?m)^\[make-new-pre-release\]$/
promoteToReleasePattern = ~/(?m)^\[promote-to-release\]$/

}

Pralhadb commented 7 years ago

Could you please help me out with this issue, that it is not working with promote-to-release.

vivin commented 7 years ago

What error message did you get?

Pralhadb commented 7 years ago

Hi Vivin,

Thanks for your response.

When I am doing any changes and trying to commit with "Promote-to-release", on build of printversion it fails saying some error like creating promote to release is not possible.......

Example, I am trying on version 2.1.1-SNAPSHOT, it should be 2.1.1 after build of printversion , but it fails.

Pralhadb commented 7 years ago

Hi Vivin,

Should I need to do any changes or it is possible to fix from your end. The actual error message is as follows:

$ gradlew printversion

FAILURE: Build failed with an exception.

BUILD FAILED

Pralhadb commented 7 years ago

$ gradlew printversion --stacktrace

FAILURE: Build failed with an exception.

BUILD FAILED

Total time: 8.643 secs

Pralhadb commented 7 years ago

kindly look into above error details and please let me know solution for this.

Pralhadb commented 7 years ago

i am trying for the requirement is to create release version from Snapshot version. Ex: current version: 2.1.1-SNAPSHOT new version should be release one. that is: 2.1.1

please provide your help.

vivin commented 7 years ago

So your commit message contains [promote-to-release] or something similar?

You can only promote pre-release versions to release versions. The documentation explains this. I suspect you're simply trying to create a release version (i.e., one without the snapshot suffix). For that, you only need to supply -Prelease.

By default, if it doesn't find any matching commit-messages, it will bump the version with the least-precedence, which is the patch version unless the latest version is a pre-release version, in which case it will bump that according to the bumping scheme that you have defined.

Pralhadb commented 7 years ago

hi, I tried with the commit message which contains [promote-to-release] .

For that, I only need to supply -Prelease. that means , I need to do this change in : newPreReleasePattern = ~/(?m)^[make-new-pre-release]$/ here to PreReleasePattern = ~/(?m)^[prerelease]$/ like this.

OR i need to give commit message as [Prelease]

Pralhadb commented 7 years ago

I tried with snapshot suffix only. but, still it shows above error.

vivin commented 7 years ago

You cannot use [promote-to-release] because that only works if the previous version is a pre-release version. What you're trying to do is create a new release version (i.e., one that is not a snapshot) with the patch-version bumped. For that, your commit message needs to contain a pattern that tells it to do that; [patch] is the default, I believe. So you will need to amend your commit message and use [patch] instead (or whatever pattern you have configured to bump the patch version).

If you do this, gradle printVersion will show 2.1.1-SNAPSHOT. If you want to create a non-snapshot version, you need to supply -Prelease; gradle printVersion -Prelease will then show 2.1.1.

Note: As I mentioned earlier, that is not strictly necessary since by default even if there are no matching commit messages, the plugin will bump the version with the lowest-precedence.

vivin commented 7 years ago

@Pralhadb Were you able to fix the issue?

Pralhadb commented 7 years ago

hi vivin,

I tried with the option which you suggested: gradlew printversion -Prelease it gives release version by removing the identifier- SNAPSHOT. But, we need to do it automatically in the same way how works for major & minor i.e., by commit message.

as per your suggestion, I tried as below: if current version is 1.1.2, on commit message= [bump-patch], it gives 1.1.3-SNAPSHOT. if 1) On this version commit = [promote-to-release], it gives error as "Bumping any component while also promoting a pre-release is not supported"

or 2) commit =[make-new-pre-release] , it gives error as "Cannot create a new pre-release if pre-release configuration is not specified. "

also, trying to add some changes in 'semantic-build-versioning.gradle':

preRelease {

startingVersion = '0.1.0-alpha.0'
// The bumping scheme is alpha.0 -> alpha.1 -> ... -> alpha.n
bump = {
 "alpha.${((it - ~/^alpha\./) as int) + 1}"
}

}

kindly tell me what is the correction i need to do or any changes i have to do.

vivin commented 7 years ago

Well, the ability to mark it as a release via commit message isn't really supported; is there a reason that you cannot use -Prelease? Are you also deploying snapshot versions? Couldn't pre-release versions be used for that?

It seems strange that you would get the "pre-release configuration is not specified" when you have the pre-release configuration. I don't see why this could be it, but I notice that your starting pre-release identifier is in the wrong format; you only need to provide alpha.0.

vivin commented 7 years ago

You cannot mix and match certain bump directives; I believe it is called out in the documentation.

You cannot promote to release while also bumping a component. You will have to amend your commit to remove that pattern.

vivin commented 7 years ago

The issue seems to be that you have multiple commits since the last tag, which seem to be mixing together making a new pre release, promoting a pre release, bumping a pre release, and bumping some other component.

Pralhadb commented 7 years ago

hi vivin,

Isn't there any option which will promote the snapshot version to release version directly and automatically? I might wrong to get the criteria for promoting the pre-release.

Pralhadb commented 7 years ago

i am working on the same task which user- @darlenya discussed with you.

vivin commented 7 years ago

@Pralhadb

Well, it really depends on your CI process. Are you actually deploying snapshot versions? What criteria do you currently use to determine whether you should be deploying snapshot versions or a non-snapshot version?

vivin commented 7 years ago

@Pralhadb were you able to figure this out?

darlenya commented 7 years ago

Hi Vivin, in our ci Process we have no suffix as RELASE or SNAPSHOT at all. We are doing semantic release as it is usual for Java Script versioning in NPM. So we would like to deploy (on the test system) every version.

vivin commented 7 years ago

@darlenya So in your CI process I assume you just explicitly set -Prelease?.

It's not clear to me how to solve @Pralhadb's issue because I'm not sure how his CI process works.

darlenya commented 7 years ago

No, we did not set anything explicitly. The idea was to deploy every commit (ONLY the excepted pull requests) as a real version. So all the suffixes as "prerelease" or "release" are not needed. And every one should aged and published. Thats how the CI process works. And we did not find out how to directly tag a fix as a new release. As a fix always contains the suffix 'prerelease'.

vivin commented 7 years ago

Closing this issue due to lack of information.