Skip to content
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

Closed
akuntsch opened this issue Mar 7, 2018 · 12 comments
Closed

Allow SNAPSHOT versions in release branches #98

akuntsch opened this issue Mar 7, 2018 · 12 comments

Comments

@akuntsch
Copy link

akuntsch commented Mar 7, 2018

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
Copy link
Contributor

raehalme commented Mar 7, 2018

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
Copy link

Steve973 commented Apr 2, 2018

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
Copy link
Contributor

hfatela commented Apr 27, 2018

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
Copy link

Steve973 commented Apr 27, 2018 via email

@aleksandr-m
Copy link
Owner

@akuntsch @alsanrum 1.10.0 is out.

@akuntsch
Copy link
Author

akuntsch commented Aug 3, 2018

Thanks. I'll have a look :)

@hfatela
Copy link
Contributor

hfatela commented Aug 3, 2018 via email

@hfatela
Copy link
Contributor

hfatela commented Aug 3, 2018 via email

@aleksandr-m
Copy link
Owner

@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
Copy link

philharperv commented Aug 14, 2018

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
Copy link
Contributor

hfatela commented Aug 16, 2018 via email

@philharperv
Copy link

@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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

6 participants