Strategy to handle versioning from merge of release branch to master, version from branch name.

[pi3k14]

Description

An PR for discussing #2242.

Not sure if this should be fixed with its own strategy. Maybe a better solution would be to adjust VersionInBranchNameVersionStrategy and TrackReleaseBranchesVersionStrategy, and configure master branch as Tracks Release Branches?

Have a look at TODO's in VersionInMergedBranchNameScenarios, I think there is some wrong calculations of the commit counts. And test TakesVersionFromNameOfRemoteReleaseBranchInOrigin was a false positive, there was another strategy that made it work (version in commit message).

Related Issue

#2242

Motivation and Context

This PR helps with generating correct version number in master when merge commit to master lacks version information.

How Has This Been Tested?

Created a test class for this new strategy and enhanced integration tests in VersionInMergedBranchNameScenarios.

Checklist:

• My code follows the code style of this project.
• My change requires a change to the documentation.
• I have updated the documentation accordingly.
• I have added tests to cover my changes.
• All new and existing tests passed.

[asbjornu]

The tests are failing. Can you please look into that? Regarding the TODOs, I think that since develop is ContinuousDeployment by default and the merge commit is counted from the base version 2.1.0-alpha.1, the result becomes 2.1.0-alpha.2.

[pi3k14]

The tests are failing. Can you please look into that?

I assume you are referring to TakesVersionFromNameOfRemoteReleaseBranchInOrigin().
That was a false positiv, the test worked because it took version from merge commit message. I changed the setup to fix that and the test fails - probably I should have left that along and registered a bug instead.

Regarding the TODOs, I think that since develop is ContinuousDeployment by default and the merge commit is counted from the base version 2.1.0-alpha.1, the result becomes 2.1.0-alpha.2.

Is there some documentation that can shed some light on this? In these cases the version number has been incremented, shouldn't then commit count be reset?

[asbjornu]

Is there some documentation that can shed some light on this?

Yes, you can read more about ContinuousDeployment in the documentation.

In these cases the version number has been incremented, shouldn't then commit count be reset?

The commit count is reset on a release, which corresponds to a tag. If you did a git tag after the merges, I expect the commit count to be reset.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. After 30 days from now, it will be closed if no further activity occurs. Thank you for your contributions.