create Release candidate (1.0.0-RC1)

[Mabmessaoud]

Hello,
as part of one of our maven projects, we used your plugin for setting up gitflow. the plugin in its standard use is perfect. however to create release candidates I would like to update the version in the pom.xml of the release branch to 1.0.0-RC1 and with each commit we increment the RC index to update the version to RC2,..., RCn .

Let me explain, suppose I have 1.0.0-SNAPSHOT on develop and when I use gitflow:release-start I would like to have a branch release "release / 1.0.0" with a maven version 1.0.0-RC1.
would it be possible to put this workflow with this plugin.

we use maven 3.8.1, java 11 and gitlab-CI

Thank you.

[aleksandr-m]

@Mabmessaoud What the issue here? You can change version to increment RC.

[aleksandr-m]

@Mabmessaoud Ping

[ulquio]

HI @aleksandr-m
First of all , I would like to thank you for the plugin, since i installed it on our project it made it much easier for us to manage the lifecycle of our gitflow project.
It has become essential , thank you for your hard work !

I will rejoice on @Mabmessaoud request and agree on the usefulness of this option !
In our project we manage release candidate too and it would be very useful to be able to configure a custom suffix ( like atlassian jgitflow plugin do : https://bitbucket.org/atlassian/jgit-flow/wiki/goals/release-start#!releasebranchversionsuffix) when we invoke gitflow:release-start
Currently we have only stable release ( ex : 1.0.0 ) or release with snapshot( with useSnapshotInRelease parameter) but some projects needs the use of release candidates before validate a stable release

Thank you very much !

[aleksandr-m]

@ulquio So it will append some string to version in the pom, but leaves branch name as it is? And what's next? How it will be incremented? By hand? Why not to change it after release-goal?

[ulquio]

@aleksandr-m
Exactly !
Say you have a version 1.0.0-SNAPSHOT , when you do the release-start goal , if we have a RC in the plugin , the version ( or revision property) should become 1.0.0-RC and the branch should stay release/1.0.0
Then , using your CI tool you can increment the RC number for tracking more efficiently the state of the release branch and the artifact deployed in QA environment

For example , what i am currently doing with Jenkins ( jenkinsfile) in conjonction with your wonderful plugin

stage('Set version') {
	steps {
		script {
			if (env.BRANCH_NAME.startsWith('release/')) {
				VERSION = "${GIT_BRANCH.replaceAll('/', '-').replaceAll('origin-', '').replaceAll('release-', '')}" + '-RC-' + "${env.BUILD_NUMBER}"										
				configFileProvider([configFile(fileId: 'Global_Maven_Settings', variable: 'MAVEN_SETTINGS_XML')]) {
					sh "mvn --no-transfer-progress -s $MAVEN_SETTINGS_XML -N versions:set-property -Dproperty=revision -DnewVersion=$VERSION -DgenerateBackupPoms=false"
				}
			stash includes: 'pom.xml' , name: 'parent_pom'										
			}
		}	
	}
}

Thank you very much

[aleksandr-m]

I don't see much benefit introducing this property to plugin, you still need some script to update it and you can run it after release-start goal as well. But I'm happy to review / accept PR-s.

[Steve973]

Hello @aleksandr-m . I would like a plugin-managed feature like this, too. I would describe the precise operation as follows:

1. Start with a maven version of 1.0.0-SNAPSHOT
2. Run mvn gitflow:release-start
3. A branch called release/1.0.0 is cut, and the version in the branch has a qualifier of "RC1" like this: 1.0.0-RC1
   a. Option for adding a release candidate qualifier -- e.g., -DrcQualifier with the default value being "RC1"
   b. Option to tag the release candidate version with the qualifier value as the default dependent on the -DrcQualifier option
4. Testers test, and developers add commits to address issues
5. When ready, developer runs another release goal, such as gitflow:release-increment-qualifier that increments the qualifier to the next integer
   a. Option for this stage to also merge to the dev branch -- e.g., -DmergeDevelop
   b. Option to tag the release candidate version with the qualifier value as the default
6. Now the release branch version is 1.0.0-RC2
7. Repeat steps 4 through 6 until testing is complete, resulting in a version of 1.0.0-RCN
8. Developer invokes mvn gitflow:release-finish

I agree with your point that you can just change the version however you want to change it on the release branch. But, to have this automated, along with optional merging down to dev, and creating tags, makes this a lot more convenient and simpler for people who are maintaining the git repo, and the release process.

I do not mind contributing, if this is something that you might not have time to do. I might need some pointers on a general approach (for the way that you might do it). I could script this in bash, but it seems like such a common use case when releasing software that it seems like many, many people would find this useful.

Either way, please let me know your thoughts. And thank you for your time and for writing this useful plugin.

[Steve973]

I was working on this today, and I have it almost finished. I have a couple more test cases to write, and then everybody can review it and see if it seems useful.

[Steve973]

@aleksandr-m If this is under ASL 2.0, can you really say that it is under a copyright owned by you? I am just wondering because I added the license comment text to a mojo file that I added.

[aleksandr-m]

I've made version update goal for updating versions in support branches for #269. It can be adjusted to be able to update version in release branch as well. So, this part is almost finished. Stay tuned.

[aleksandr-m]

Version update goal is ready.

[dagutten]

It seems that doing a release-finish will move the -RC* suffix to the master branch.

Would be possible to have a digitsOnlyMasterVersion as we already have digitsOnlyDevVersion ?

The intention is to remove the "-RC1" on the master branch after "release-finish", replacing "1.1.0-RC1" to "1.1.0" in Master, finally tagging as 1.1.0.

[aleksandr-m]

@dagutten Can you create a separate issue for this.

[tofik-mamishov]

It seems that doing a release-finish will move the -RC* suffix to the master branch.

Would be possible to have a digitsOnlyMasterVersion as we already have digitsOnlyDevVersion ?

The intention is to remove the "-RC1" on the master branch after "release-finish", replacing "1.1.0-RC1" to "1.1.0" in Master, finally tagging as 1.1.0.

@dagutten @aleksandr-m Is there any update on this?