-
-
Notifications
You must be signed in to change notification settings - Fork 183
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Allow SNAPSHOT versions in release branches #98
Comments
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. |
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. |
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. |
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>
.
|
Thanks. I'll have a look :) |
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>
.
|
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>
.
|
@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. |
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.
The only config I have set outside of the flow context is commitDevelopmentVersionAtStart=true and useSnapshotInRelease=true. Thanks, Phil |
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>
.
|
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 propertycommitDevelopmentVersionAtStart
totrue
.Current behaviour
gitflow:release-start
changes the development version to1.0.1-SNAPSHOT
and creates a release branchrelease/1.0.0
with version1.0.0
Wanted behaviour
gitflow:release-start
changes the development version to1.0.1-SNAPSHOT
and creates a release branchrelease/1.0.0
with version1.0.0-SNAPSHOT
Setting the release version to
1.0.0-SNAPSHOT
with thereleaseVersion
property has the consequence that the release branch will be namedrelease/1.0.0-SNAPSHOT
, which is also not desirable.The text was updated successfully, but these errors were encountered: