Unable to create minor version when release candidate is in review

[SooryakumarThoppan]

Currently we are trying to use reckon plugin to do semantic versioning. Expecting developers to create beta artifact & merge the code into master branch. QA creates rc artifact and test to move it to final. Tagged these artifacts at different stages

With given above flow, two different developers created two branches and tested the changes and merged the code into master branch separately. So it created two different rc candidates.. Ex., 1.1.0.rc.1 and 1.1.0.rc.2

While 1.1.0.rc.1 is in pending review with QA, expecting developer to create a branch to work on minor version and expected version should be 1.2.0.beta.1. But while running the gradle assemble command 'gradlew clean assemble -Preckon.scope=minor -Preckon.stage=beta' It is trying to generate 1.1.0.beta.1 instead of 1.2.0.beta.1. Please help how to achieve it

[ajoberstar]

A few questions:

• What version of reckon?
• What does your reckon {} block in the build.gradle look like?
• Is the developer's branch up to date with master? (i.e. is the commit tagged 1.1.0-rc.1 in the history of the developer's branch?

[SooryakumarThoppan]

Thanks for the response.

1. Version is, 'org.ajoberstar.reckon' version '0.16.0'

2. Reckon Block is, reckon { stages('beta','rc', 'final') scopeCalc = calcScopeFromProp() stageCalc = calcStageFromProp() }

3. Is the developer's branch up to date with master? (i.e. is the commit tagged 1.1.0-rc.1 in the history of the developer's branch) Yes. Git Command is, git tag on the developer branch is,

   git tag 1.0.0 1.1.0-beta.1 1.1.0-beta.2 1.1.0-beta.3 1.1.0-beta.4 1.1.0-beta.5 1.1.0-rc.1 1.1.0-rc.2

[ajoberstar]

Can you show a git log from your developer branch?

git log --graph --oneline --decorate <developer branch>

[SooryakumarThoppan]

>git log --graph --oneline --decorate feature/CD-5602-versioninghappypath
* 844d8c3 (HEAD -> feature/CD-5602-versioninghappypath, origin/feature/CD-5602-versioninghappypath) CD-6502- build gradle changes
*   9c62c83 (tag: 1.2.0-rc.1, origin/master, origin/HEAD) Merge pull request #6 from xxx/feature/CD-5602-versioninghappypath
|\
| *   0089e84 Merge branch 'master' of https://github.com/xxx/java-source into feature/CD-5602-versioninghappypath
| |\
| |/
|/|
* |   3784ac6 Merge pull request #5 from xxx/Feature/build-gradle-fixes
|\ \
| * | 39f2daa Fix to build.gradle for reckon plugin, also upgrade to version 0.16
|/ /
| * c2c704e CD-6502- build gradle changes
| * 31af409 CD-6502- reckon version changes
| * 925190e CD-6502- remove warnings while compiling
|/
*   6be0446 (tag: 1.1.0-rc.2) Merge pull request #4 from xxx/feature/CD-5602-versioninghappypath
|\
| * e2f31f5 CD-5602- removed unnecessary import
| * 5840070 CD-5602- removed unnecessary changes
| * 7fd3cb6 CD-5602-gradlew batch file and controller changes
| * eca3609 CD-5602-gitignore changes
| * c851bbf CD-5602-gitignore changes
|/
*   48de909 (tag: 1.1.0-rc.1, master) Merge pull request #3 from xxx/Feature/clean-build-with-java-source
|\
| * b4ab342 (tag: 1.1.0-beta.5) Fixed reference to code artifact environment variable in build job.
:...skipping...
* 844d8c3 (HEAD -> feature/CD-5602-versioninghappypath, origin/feature/CD-5602-versioninghappypath) CD-6502- build gradle changes
*   9c62c83 (tag: 1.2.0-rc.1, origin/master, origin/HEAD) Merge pull request #6 from xxx/feature/CD-5602-versioninghappypath
|\
| *   0089e84 Merge branch 'master' of https://github.com/xxx/java-source into feature/CD-5602-versioninghappypath
| |\
| |/
|/|
* |   3784ac6 Merge pull request #5 from xxx/Feature/build-gradle-fixes
|\ \
| * | 39f2daa Fix to build.gradle for reckon plugin, also upgrade to version 0.16
|/ /
| * c2c704e CD-6502- build gradle changes
| * 31af409 CD-6502- reckon version changes
| * 925190e CD-6502- remove warnings while compiling
|/
*   6be0446 (tag: 1.1.0-rc.2) Merge pull request #4 from xxx/feature/CD-5602-versioninghappypath
|\
| * e2f31f5 CD-5602- removed unnecessary import
| * 5840070 CD-5602- removed unnecessary changes
| * 7fd3cb6 CD-5602-gradlew batch file and controller changes
| * eca3609 CD-5602-gitignore changes
| * c851bbf CD-5602-gitignore changes
|/
*   48de909 (tag: 1.1.0-rc.1, master) Merge pull request #3 from xxx/Feature/clean-build-with-java-source
|\
| * b4ab342 (tag: 1.1.0-beta.5) Fixed reference to code artifact environment variable in build job.
| * a695545 (tag: 1.1.0-beta.4) Fix to the maven publish command.
| * 41ae076 (tag: 1.1.0-beta.3) Attempt to fix path to local lib jars.
| * 794d48a (tag: 1.1.0-beta.2) Changed to use CODEARTIFACT_TOKEN variable
| * 85e8235 (tag: 1.1.0-beta.1) Removed reference to old POC project.
| * 3fb50fb Added/configured reckon plugin to the feature branch.
| * 061753c Added all java source files to feature branch.
|/
* f814c69 Removed gradle project so we can rebuild with good JavaSource code.
*   0a952fd (tag: 1.0.0) Merge pull request #1 from xxx/Feature/reckon-setup
|\
| * ff33d29 Reckon setup
|/
* 9bc0789 Updating build commands
* 196fb11 Adding echo TAG Command

[ajoberstar]

What may be throwing things off is the lack of 1.1.0 (final) and/or 1.2.0 (final) in the history. In this example, reckon would be using 1.0.0 as the "base normal" it increments from. And since all of these tags are in the feature branch's history, none of the parallel branch logic would come into play either.

[SooryakumarThoppan]

As per our expecting flow, 1.1.0 is the final version, which we think to convert after qa testing of 1.1.0-rc-1 & 1.1.0-rc.2 completed. 1.1.0-rc.1 & 1.1.0-rc.2 are two different release candidates(based on commit)

Also, we are pushing the tags to remote by using git push --tags once after the build is successful. Wouldn't it be a bug as it as it has 1.1.0-rc.2 is the latest? If this the intended reckon flow, should developers to wait until the final version?

Would you pls recommend the configuration to achieve the below process if above understanding of our plugin is incorrect?

As per our understanding, we try to leverage three stages beta, rc and final in our project.

1. Beta is something developer makes changes and tag beta version based on its scope.
2. once beta is tested and raise pull request to lead to review the code and once the changes are approved.
3. will merge the feature branch into master branch and tag rc candidate for qa testing
4. likewise, there are other developer who does changes in feature branch and follow steps 2 and 3 in parallel to tag rc for qa testing.
5. QA testing would take time to test all the master and certify its readiness

6. At one point, consolidate all the rc candidates and creates the final version of artifact

   Is above scenario is possible with this plugin? Am working on this POC to implement in our artifacts or not. if this feature is not supported, we cannot use this plugin

[ajoberstar]

For reckon, tagging versions from a feature branch isn't a great idea as it can cause a bit of a spaghetti mess of tags when some feature branches are inevitably closed without merging to master. I'd suggest publishing "insignificant" versions from feature branches (omit the -Preckon.stage=beta property) which will look like 1.2.0-rc.1.1+844d8c3 in the case of the git history you shared. These will not be tagged but can still be published to a Maven repo (or wherever).

Without the tagging of beta versions on your feature branches, I don't see any other problems that you'd have with reckon in your workflow.

In the example history you have, trying to tag a minor beta would:

1. Find that 1.0.0 is the nearest final version in your history
2. Increment that with a minor to get 1.1.0
3. Try to set the stage to beta resulting in 1.1.0-beta.1
4. This should fail since 1.1.0-beta.1 is lower than 1.2.0-rc.2 which is the nearest tagged version (same would be true 1.1.0-rc.2, since beta < rc)

Reckon doesn't expect (or support) you to go backwards on stages for a targeted final version. If you instead wanted it to jump ahead a version, that only applies when Reckon sees a parallel branch that has a tagged version that conflicts with what you're trying to tag on HEAD.

So if the insignificant version approach will work for you, reckon should meet your needs. If you're really looking to leverage beta as described, it's won't be a good fit.

[SooryakumarThoppan]

great. thanks for the suggestion & recommendation. Let me check with different scenarios and update this thread with outcomes

[SooryakumarThoppan]

I have tried few scenarios and need a help

Scenario 1: Having two release candidates in the master branch 0.1.0-rc.1 0.1.0-rc.2 QA testing rc.1 and try to make rc.1 alone a final version. Is it possible to create the final version based on specific tag?

Scenario 2: Having three release candidates(2 minor and 1 major) in the master branch 0.1.0-rc.1 0.1.0-rc.2 1.0.0-rc.1 Tried to create minor final versions. plugin doesn't allowed it. Seems as you mentioned in earlier response, reckon doesn't support going backwards. So, in this case, major release contains both minor release candidates changes. Is my understanding correct?

[ajoberstar]

This flow's probably not going to work well with reckon. As you noted, reckon doesn't support versions being out of order in history (see this doc. You might be able to work around it by checking out 0.1.0-rc.1 and running running reckonTagPush, but you could hit other complications.

In scenario 2, if you were working towards two separate versions (0.1.0 and 1.0.0), reckon would expect those to be on separate branches, in which case the branch with 0.1.0-rc.2 could be released as 0.1.0.

[SooryakumarThoppan]

Thank you for the response! still am trying to evaluate the reckon plugin against the "Trunk Based Development".

Need a quick thought of yours on using reckon on TBD approach. In which, we have only master and release branches. Feature branches are short lived. It should accommodate bug fixes on old releases.

How these stages to be utilized for Developer code changes -> QA testing -> release the final artifact