Allow SNAPSHOT versions in release branches

[akuntsch]

Currently when I have a -SNAPSHOT version in the development branch and I start a release, the release branch will have the development version without -SNAPSHOT.

As a result, builds of the new release branch will produce production artifacts (as the version is the one which will eventually end up in the production branch) which should normally only happen when building the production branch, i.e. after finishing the release.

Let's say we have a development branch with version 1.0.0-SNAPSHOT and we set the property commitDevelopmentVersionAtStart to true.

Current behaviour

gitflow:release-start changes the development version to 1.0.1-SNAPSHOT and creates a release branch release/1.0.0 with version 1.0.0

Wanted behaviour

gitflow:release-start changes the development version to 1.0.1-SNAPSHOT and creates a release branch release/1.0.0 with version 1.0.0-SNAPSHOT

Setting the release version to 1.0.0-SNAPSHOT with the releaseVersion property has the consequence that the release branch will be named release/1.0.0-SNAPSHOT, which is also not desirable.

[raehalme]

Instead of keeping the release branch version as a SNAPSHOT you could also just deploy to a staging repository which allows re-deploys until you finish the release.

If you want to improve even further you can use the gitflow-helper-maven-plugin to accomplish this and more.

[Steve973]

You might not really need a -SNAPSHOT qualifier. Since your code is in a release branch, a qualifier of -RC (throughout the entire release candidate cycle) or RC (iteratively incrementing for each release candidate, like RC1, then RC2, then RC3...) seems to be sufficient. To me, SNAPSHOT seems to be a development branch construct.

[hfatela]

We started to use this plugin last year and this is the only issue we have open at the moment and we really miss. We need a way for the user to set a optional qualifier (like SNAPSHOT or RC) for hotfix and release. By default doesn't add one, by using a parameter we can set whatever qualifier we want.

[Steve973]

I concur that having separate development branch, release branch, and master branch versions would be ideal. The question remains, really, about whether or not an -RC or -RC<number> qualifier is entirely necessary for a release branch and for when you deploy a release candidate to an integration environment. But people will definitely want that. Regarding hotfixes, in gitflow, it is branched off of a release, and it probably doesn't need a separate qualifier. Just my thoughts, though, and other perspectives are good for the discussion.

…

On Fri, Apr 27, 2018 at 6:14 AM, hfatela ***@***.***> wrote: We started to use this plugin last year and this is the only issue we have open at the moment and we really miss. We need a way for the user to set a optional qualifier (like SNAPSHOT or RC) for hotfix and release. By default doesn't add one, by using a parameter we can set whatever qualifier we want. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#98 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/APqR2_PbZvMUJPKKlqlfPAjEGzFgW22yks5tsu-ggaJpZM4SgujQ> .

[aleksandr-m]

@akuntsch @alsanrum 1.10.0 is out.

[akuntsch]

Thanks. I'll have a look :)

[hfatela]

hi, I think I found a bug in the release-start. It wasn't accepting the new parameter. I looked at the code: GitFlowReleaseStartMojo.java you have: /** * Whether this is use snapshot in release. * * @SInCE 1.10.0 */ @parameter(defaultValue = "false") protected boolean useSnapshotInRelease; I think it should be: /** * Whether this is use snapshot in release. * * */ @parameter(property = "useSnapshotInRelease", defaultValue = "false") protected boolean useSnapshotInRelease; I found the same problem in GitFlowReleaseFinishMojo.java. Regards

…

On Fri, Aug 3, 2018 at 6:30 AM akuntsch ***@***.***> wrote: Thanks. I'll have a look :) — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#98 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ATz6NoTGJY_7pwZiSyKPu0FV5hbBt3-wks5uM9_fgaJpZM4SgujQ> .

[hfatela]

The hotfix start and finish also has the same problem: current: @parameter(defaultValue = "false") expected: @parameter(property = "useSnapshotInHotfix", defaultValue = "false")

…

On Fri, Aug 3, 2018 at 6:30 AM akuntsch ***@***.***> wrote: Thanks. I'll have a look :) — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#98 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ATz6NoTGJY_7pwZiSyKPu0FV5hbBt3-wks5uM9_fgaJpZM4SgujQ> .

[aleksandr-m]

@hfatela It is by design. Setting it from the command line can lead to errors if someone forgets to put it in the finish goal.

Put it in your project's pom.

[philharperv]

I am trying to use this feature but am running into issues when I run release-finish.

I am running release-start which first takes a release branch from develop and then increases the SNAPSHOT version in develop.

When I run release-finish the SNAPSHOT is removed in the release branch and then merged into master and develop, but I am getting conflicts when the plugin is trying to merge the release branch back into develop, as seen below.

++<<<<<<< HEAD
 +        <version>0.4.2-SNAPSHOT</version>
++=======
+         <version>0.4.1</version>
++>>>>>>> release/0.4.1

The only config I have set outside of the flow context is commitDevelopmentVersionAtStart=true and useSnapshotInRelease=true.

Thanks,

Phil

[hfatela]

Hello, I hit the same problem. I dig into the code and apply the same solution the old gitflow did. The only way to solve this is to set the version of the release into the develop branch before the merge and later revert this change back. I'm still testing this out and so far so good, the merge problem is gone. I found another error in the hotfix finish of support branches that I'm still correcting, as soon I finish I will send both corrections to Alek for review. But, if you are in a hurry and want to try the correction just clone my project https://github.com/hfatela/gitflow-maven-plugin and create a jar from there. Regards Hugo

…

On Tue, Aug 14, 2018 at 9:38 AM philharperv ***@***.***> wrote: I am trying to use this feature but am running into issues when I run release-finish. I am running release-start which first takes a release branch from develop and then increases the SNAPSHOT version in develop. When I run release-finish the SNAPSHOT is removed in the release branch and then merged into master and develop, but I am getting conflicts when the plugin is trying to merge the release branch back into develop, as seen below. ++<<<<<<< HEAD - <version>0.4.2-SNAPSHOT</version> ++======= - <version>0.4.1</version> ++>>>>>>> release/0.4.1 The only config I have set outside of the flow context is commitDevelopmentVersionAtStart=true and useSnapshotInRelease=true. Thanks, Phil — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#98 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ATz6NnC0qQdtKtb9UWOTDU54pNAlAo0qks5uQoyXgaJpZM4SgujQ> .

[philharperv]

@hfatela I have created a separate issue regarding this as I thought it required a separate ticket. Thank you for looking into it and hopefully providing the fix that will sort this.

The new issue can be found at #122