Feature request: add parameter noReleaseMerge to release and release-finish goals

[liqidator]

We work on two versions in paraller. On develop we have 1.1, in release branch there is 1.0.
What I need is to be able to release both versions whenever needed.

However, when I do release from develop, I don't want to merge to master, because there should be 1.0 only as it is production version.

I am trying to go around this.

When I used jgitflow maven plugin, there was an option noReleaseMerge, I would need something similar.
https://bitbucket.org/atlassian/jgit-flow/wiki/goals/release-finish

I think it is very useful. Or is there any other way to prevent merging to develop/master?

[aleksandr-m]

What do you call a release then? How do you release master?

Are you aware of the support-branches?

[liqidator]

We are not in production yet.
Now that you mention that, it seems that we should have not started development in develop branch, but we should have used master instead. It would have been better.
On Master there is always latest released version.
We release from develop (1.1) and from release branch (1.0).
Perhaps we should have 1.0 on master instead. Am I correct?

Anyway I find noReleaseMerge parameter quite useful.

[liqidator]

How do you proceed, when you have version A on master, version B in UAT tests and version C, which is new development? And you need to be able to release B and C and deploy them on the separate test environments?
We put version C on develop and version B on release branch ... but during releasing the changes get merged to master, which is wrong.

[liqidator]

We use scrum. At the end of sprint we produce PSI and release a new version (no SNAPSHOT). It is production-ready code. But this release should not be merged into master.

[liqidator]

I don't quite see a reason, why there should be just one release branch. Even bitbucket supports multiple release branches and even merges automatically from older ones to newer ones.
Gitflow plugin should allow releasing from multiple release branches.
https://confluence.atlassian.com/bitbucketserver/automatic-branch-merging-776639993.html

[raehalme]

I'm not sure I undertand, but isn't the whole purpose of using prefixes on branch names that you can have multiple branches when necessary?

You have 1.0 in master and you are preparing and testing the release of 1.1 on a release branch release/1.1 while already developing the features for 1.2-SNAPSHOT on develop. You can already do that with the current version.

If it takes a long time to finish with the 1.1 version and you want to push 1.2 to testing, you could start the release process also on 1.2 on a branch of its own, ie. release/1.2 and move develop to 1.3-SNAPSHOT. I'm pretty sure you can do this as well.

What am I missing here? :-)

[liqidator]

Yes, I could create second release branch, but I will not be able to perform release using gitflow plugin as it will fail with 'Release branch already exist)' error.
We want to deploy production-ready (NO SNAPSHOT) versions after every sprint for 1.1 and 1.2, but we can't

[raehalme]

I can't see how the plugin would fail with such an error if you're defining a distinct version for each release.

1. You're in develop and want to start a release of version 1.1.

• Use mvn gitflow:release-start to start the release process on develop.
• Set version to 1.1 and the plugin creates a branch release/1.1 for you.
• There is no SNAPSHOT in the version number.
• Test and modify the branch release/1.1 until you're satisfied with the release.

2. Meanwhile continue development on the develop branch with version 1.2-SNAPSHOT.

• Let the plugin bump the version number on the develop branch when starting the release on step 1, see commitDevelopmentVersionAtStart.

3. When your sprint ends and you want to make another release, just repeat step 1 with the version you want to release.

• When you use mvn gitflow:release-start on develop and provide, for example, version 1.2, the plugin creates branch release/1.2 for you. As long as this is a new version there should be no collision in branch names.

This functionality is already available.

[liqidator]

Thanks Thomas for thorough explanation.
I want to add that I need to bump versions on both develop (1.2) and release branch (1.1) incrementing merely patch versions.
But I cannot complete mvn gitflow:release-finish without merging to master as it is integral part of release-finish. There can be only one version on master.

[raehalme]

I'm not sure I understand the problem with master. When you finally release 1.1, you should merge it to master. Then after you finish with the 1.2 release, you merge it to master. You can have multiple versions in the release process simultaneously, but only one, i.e. the latest goes into master.

If you need to maintain old versions simultaneously, maybe you should then checkout the support branches as @aleksandr-m suggested?

[liqidator]

Let me rephrase it.
Can I bump patch versions without having to perform a release? For example I keep release branch on version 1.2.1, then I need to bump version to 1.2.2 (along with pushing artifacts to nexus) and then 1.2.3.
Eventually, when moving to production I need to finish release and merge it to master.

[raehalme]

That sounds a bit problematic. The very least you'll run into merge conflicts when you have many branches changing the project version in pom.xml.

How about you have a look at this plugin which you could use to implement staging? Then you don't need to bump the version when making changes on the release branch. You can just redeploy the same version into a staging repository until you're done. When finally merging the release to master, the plugin will move the artifacts from staging into the production repository.

We're actually using this method ourselves and it works pretty well. Send me a PM in case you need further instructions. I'm happy to help.

[raehalme]

I did some further testing and you're right the plugin checks for the existence of any release branch, and when you have one active you cannot create another.

What do you think @aleksandr-m shouldn't it be possible to run multiple release branches simultaneously? It might be little problematic in practice, but is there need to prevent it altogether?

[aleksandr-m]

@raehalme In the original git-flow there can be only one release branch at a time. There was some previous discussion about it in #23.

shouldn't it be possible to run multiple release branches simultaneously?

I think it can be confusing to have more than one release branch.

[aleksandr-m]

@liqidator Why can't you merge to master? What is the purpose of the master branch in your workflow?

There is tags in master if you need to deploy some previous version to production.

[liqidator]

Master contains production-ready, tested code. Either hotfixes or new development which passed UAT testing - but only development of the closest version.
Suppose that I have 1.0 in master, and release branches with 1.1 and 1.2 (and 1.3 on develop) I don't want 1.2 getting merged to master, it is to far away.
I would like to have an option to prevent merging while releasing.
For example, I want to release 1.2 without getting to master, just to bump patch version, create version in nexus, sonar and keep branch opened for further UAT patches.

Does it make sense? Or am I doing something wrong?
As I mention, bitbucket allows multiple release branches.

[hfatela]

In my company we reach a phase when after each 2 weeks we make a release-RCx, the idea is just to have a release candidate to send to the lab for tests while in the development branch we continue to add the last remaining features. In this release RC branch we may introduce some commits to fix some prio 1 problems found and after 2 weeks we merge it back to development, delete it and make another one, like for example RC2.
We do not want to merge these RC to Master since is not an official release. We normally continue to make RC's for 6 to 8 weeks before we reach a point we are satisfied and make a final release.
In the line of the issue raised above by liqidator can you introduce an option to finish a release and prevent a merge to master, but merging it back to develop and erasing the release branch?

[aleksandr-m]

@hfatela Why not to use feature branch for that long running release? When it is done, finish it and do a release.

[tim-rea]

@aleksandr-m I know this is an old thread, but I agree 100% with hfatela above. I have been using jgitflow maven plugin for a couple of years, and we create multiple RC builds between final releases. We use the noReleaseMerge option only for release candidate builds, and for RC builds the release branch cannot be merged to master, as master reflects the latest release and what is deployed to Prod.

As to your question above, the artifacts resulting from a build on a feature branch are never pushed to our maven repo. That would make so sense since if you have a dozen feature branches and each was being built multiple times per day, then the functionality of the latest SNAPSHOT build would change over and over. I don't see how that could work. And, since an RC build is a release, then it can be deployed to QA env for testing. We do not allow SNAPSHOT artifacts to the be deployed to QA.

So using jgitflow and noReleaseMerge for RC builds is a perfect solution that has served us well. I have recently found that jgitflow does not work for building releases of any flavor when we must use the ssh git url from Bitbucket and only the key is used for authentication and access control, and we must use the 7999 ssh port.

I have found that your gitflow maven plugin works better than jgitflow, and since it uses the git commands instead of using jgit, it works perfectly since that uses .ssh/config which provides the usage of the 7999 port and the identity. I also feel that your gitflow maven plugin provides more useful features than jgitflow.

However, since the gitflow maven plugin does not support the concept of "noReleaseMerge", I cannot use if for the reasons above. Would you consider adding it?

[aleksandr-m]

@tim-rea So with noReleaseMerge release branch should be merged into the develop and not to master. And that it?
Please confirm.

I'll take another look at it.

[tim-rea]

Thats it.

Thanks

[tim-rea]

Hi @aleksandr-m ,

Was this feature implemented? If so, which release will it be included in?

Thanks,
Tim Rea

[aleksandr-m]

@tim-rea Yes, it was. Next.

[aleksandr-m]

@tim-rea 1.15.0 is out!