Closed tvcsantos closed 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
@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 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 👍 👍
@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
@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 onrelease-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.
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
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-RCAfter finishing the release candidate branch the version will be 1.0.2