Support merging a release branch back to develop but maintain the version

[andreasohlund]

This is still WIP

We have a situation where stabilizing majors we want to merge a release branch down to develop but then keep working on it. When this is done the versioning resets back to x.y.z-beta.0+1 and ignores any prerelease tags.

I remember talking with @nulltoken about this and we said it wasn't a valid use case.

@nulltoken can you take a look at this and see if its even possible to support this? (see the failing test)

cc @SimonCropp @johnsimons @JakeGinnivan

[JakeGinnivan]

This will cause develop's version to bump? Everything else looks good to me

[andreasohlund]

Hmm, I thought only merges back to master would bump?

But in our case it wouldn't really be an issue if develop jumped to 2.1.0 in this case since that would be the correct next version for develop

Sent from my iPhone

On 01 Jul 2014, at 19:18, Jake Ginnivan notifications@github.com wrote:

In AcceptanceTests/GitHubFlow/ReleaseBranchTests.cs:

•            fixture.Repository.CreateBranch("release-2.0.0");
  

•            fixture.Repository.Checkout("release-2.0.0");
  

•            fixture.Repository.MakeCommits(1);
  

•            VerifyVersion(fixture, "2.0.0-beta.1+1");
  

•            //tag it to bump to beta 2
  

•            fixture.Repository.ApplyTag("2.0.0-beta1");
  

•            fixture.Repository.MakeCommits(1);
  

•            VerifyVersion(fixture, "2.0.0-beta.2+2");
  

•            //merge down to develop
  

•            fixture.Repository.Checkout("develop");
  

•            fixture.Repository.MergeNoFF("release-2.0.0", Constants.SignatureNow());
  

  This will cause develop's version to bump? Everything else looks good to me

—
Reply to this email directly or view it on GitHub.

[andreasohlund]

Ping @nulltoken , how hard would this be to support?

[dtabuenc]

The problem is that the current code only goes back nbHotfixCommits + 1 to search for tags. Once code has been merged into develop nbHotfixCommits is 0 since it is defined in code as the number of commits in release branch not contained in develop. In order to get the expected behavior you would need to be able to find the initial branch point of the current release branch, but this is not really possible in all situations due to how git branches work.

The use case is completely valid in my opinion. Release branches can often be moderately long-lived during a QA process, and merging hotfixes back into the develop without resetting release version is crucial.

I'm not sure why we have to limit the search for tags by nbHotfixCommits. In a modified version of the code we are running, we have switched to simply enumerating all the tags that parse as SemanticVersion and match the current release version. We also define the +n (CommitsSinceTag) as actually the commits since the previous tag (rather than the current behavior which is number of commits not in develop branch). This seems more appropriate and more aligned with the name of that metadata variable. For example, if we have a release with tag:

1.0.0-rc2

The full semver of the next commit would be:

1.0.0-rc3+0

and the commit after that would be:

1.0.0-rc3+1

The +1 would roll back to 0 for 1.0.0-rc4 etc.

I can clean up the code and submit a pull request for this if desired, I'd have to check and make sure this would not affect anything else.

[dtabuenc]

I have created a pull request for my proposed changes:

#291