search

aleksandr-m / gitflow-maven-plugin

The Git-Flow Maven Plugin supports various Git workflows, including GitFlow and GitHub Flow. This plugin runs Git and Maven commands from the command line.
https://aleksandr-m.github.io/gitflow-maven-plugin/
Apache License 2.0
493 stars 181 forks source link

Support for Release Branches Version Suffix #216

Closed tvcsantos closed 4 years ago

tvcsantos commented 4 years ago

Hi there it would be great if we have support for suffixes on release branches.

This will allow us to produce for instance release candidate branches.

For example we want to create a release branch 1.0.2 that is a release candidate. We set the parameter releaseBranchVersionSuffix=RC, when doing a release-start, and RC will be appended to the version number, like 1.0.2-RC

After finishing the release candidate branch the version will be 1.0.2

tvcsantos commented 4 years ago

@aleksandr-m It would be great if you have some time to review this PR and tell me if it makes sense for this project, or if there is a workaround that I can use to produce the same effect.

If it does make sense and there something that needs adapating I'll be glad to do it.

Thanks

aleksandr-m commented 4 years ago

@tvcsantos What benefit does it bring over just naming your release branch with suffix? Not having suffix in development branch? Maybe you can use developmentVersion parameter for that?

tvcsantos commented 4 years ago

@tvcsantos What benefit does it bring over just naming your release branch with suffix? Not having suffix in development branch? Maybe you can use developmentVersion parameter for that?

@aleksandr-m I think I get what you mean :) if I play around with releaseVersion and developmentVersion flags I might get the same effect. Thanks I'll play a bit with it and let you now what was the result 👍 👍

tvcsantos commented 4 years ago

@aleksandr-m ok I've been playing around with those two flags. But I can't produce the same effect.

releaseVersion is only available on release-start goal so I can't control the final release version when closing it.

What I wanted to achieve with this proposal was the following scenario.

Suppose that we have a project under development at version 1.2.0-SNAPSHOT, and now is the time to make a release. We use the release-start goal for that. This creates a release branch named release/1.2.0 with pom version 1.2.0 👍. This produces an artifact, but since it is not a SNAPSHOT it can be only uploaded once to a repository. Ok no problem, we use the option useSnapshotInRelease and that is solved. So now the resulting version from opening the release is 1.2.0-SNAPHOST 👍 .

Ok but we want to be able to distinguish this version while the release is open from a development SNAPSHOT version. I think we can't do it, without committing to have also the same release version when closing the release.

Using the proposed solution we can. Since we add a suffix when opening the release (release-start goal) and we will have a version 1.2.0-<suffix>-SNAPHOST that will be removed when we finish it (release-finish goal) resulting in 1.2.0.

This is more expressive and allow us to have release candidate versions. That is, artifacts that are potential releases, and are uploaded to our repository, in a testing phase of the development process. These release candidate artifacts, by using the <suffix>, can be clearly identified and distinguished from a normal development SNAPSHOT version, that does not have the <suffix>, hence being a lot less human error prone when deploying the artifact to a testing environment.

If a problem occurs while testing the potential release candidate version, then developments are kept in the release branch, and the artifacts are continually uploaded, without changing version number since it is also a SNAPSHOT.

When everything is OK and we can actually finish the release we just call the release-finish goal, that will remove both the SNAPSHOT and the <suffix>, ending up with the real release version 1.2.0 that can be safelly uploaded as a final artifact to our repository and also deployed to a production environment.

Thanks for your help.

Best, Tiago

aleksandr-m commented 4 years ago

@tvcsantos Thank you for the detailed explanation. So you are releasing multiple times from the same branch? And without incrementing version or candidate version?

releaseVersion is only available on release-start goal so I can't control the final release version when closing it.

It can be changed manually with the commit to the release branch.

I tend to avoid long lived release branches, it can get quite messy upon merging them back to develop.

One of the workflows that I saw was to start a release with rc1 suffix appended and finish it getting rc1 tag and merge commit back to develop, if another candidate is needed then another release is started with rc2 and so on.

tvcsantos commented 4 years ago

Thanks for your support on this. After reading your comments and the available flags I found out that we could use preReleaseGoals flag to achieve this 👍. We ended up doing like this when finishing a release to remove the RC suffix:

mvn -B gitflow:release-finish -DpreReleaseGoals='versions:set -DnewVersion=1.2.0-SNAPSHOT'

Thanks once again. I'll close this PR. Cheers