Question: Building develop branch without pulling master branch results in unexpected nuget versions - what is the correct approach?

[serra]

When I build the develop branch, I get unexpected nuget prerelease versions. This is because the local master branch is behind origin/master. When I pull origin/master into master before building the develop branch everything is as expected.

What is the correct behaviour here? Should I pull master before building from develop (feels a bit awkward)?

Thanks!

[JakeGinnivan]

Yes you need to fetch master for GitFlow unfortunately.

The current behavior does not bump develop when you take a release branch or merge that release branch into develop. It only is bumped when the release branch is merged to master.

Take this test

[Test]
public void MergingReleaseBranchBackIntoDevelopWithoutMergingToMaster_DoesNotBumpDevelopVersion()
{
    using (var fixture = new EmptyRepositoryFixture(new Config()))
    {
        fixture.Repository.MakeATaggedCommit("1.0.0");
        fixture.Repository.CreateBranch("develop").Checkout();
        fixture.Repository.CreateBranch("release-2.0.0").Checkout();
        fixture.AssertFullSemver("2.0.0-beta.1+0");
        fixture.Repository.Checkout("develop");
        fixture.AssertFullSemver("1.1.0-unstable.0+0");
        fixture.Repository.MergeNoFF("release-2.0.0", Constants.SignatureNow());
        fixture.AssertFullSemver("1.1.0-unstable.0+0");
    }
}

The reason for this is because breaking SemVer changes need to be isolated from mainline development most of the time. So when you are about to create a breaking change you take a release branch which bumps the major and make the breaking change on that branch.

To do it the other way around you would have to change the config file to bump the next version. And then if you decided to release a patch/minor release you would have to take a release branch off a detached head on develop before you introduced the breaking change. Which is quite unintuitive.

Happy to hear your thoughts on this and ways around it. Also @andreasohlund @SimonCropp @gep13 feel free to chime in.

In short, yes it is expected behaviour. This is one of the downsides with GitFlow, version decisions are not based on a single branch. But we can be much smarter about the intended version.

[serra]

I am fine with the current behaviour. This issue came up on my integration server, for a job only concerned with the develop branch. That job only checks out changes from the develop branch, thus always resulted in "wrong" version information. This only got inconvenient when I wanted to ship some pre-release packages build by this dev job.

Two (acceptable) workarounds for me are:

• pulling into a local master branch as a separate build step (this I currently use)
• using a nextversion.txt

[serra]

Then again - I should not release anything from develop directly when doing gitflow 😄

[serra]

BTW - in this case, I don't think we can be smarter about the intended version WITHOUT fetching from remotes. And I don't think we want to do that when calling gitversion, right?

[JakeGinnivan]

GitVersion should actually fetch remotes for you automatically...

Sent from my Windows Phone

---

From: Marijn van der Zeemailto:notifications@github.com
Sent: ý18/ý11/ý2014 17:31
To: ParticularLabs/GitVersionmailto:GitVersion@noreply.github.com
Cc: Jake Ginnivanmailto:jake@ginnivan.net
Subject: Re: [GitVersion] Question: Building develop branch without pulling master branch results in unexpected nuget versions - what is the correct approach? (#288)

BTW - in this case, I don't think we can be smarter about the intended version WITHOUT fetching from remotes. And I don't think we want to do that when calling gitversion, right?

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/288#issuecomment-63488284.

[gep13]

GitVersion should actually fetch remotes for you automatically..

Currently only when running on a Build Server.

[serra]

@gep13 how does it determine that it is on a Build Server?

[serra]

I have a Jenkins server (running on Linux) and a windows build slave. Gitversion is called on the build slave as part of the build step.

[gep13]

@gep13 how does it determine that it is on a Build Server?

You would call GitVersion as described here:

https://github.com/ParticularLabs/GitVersion/wiki/Command-Line-Tool#directly-on-build-server

i.e. with parameter /output buildserver

Gitversion will then check for the presence of an environment variable which tells it which CI Server it is running on. Once it knows that, it can take appropriate action, i.e. normalise the branches, set build numbers, etc.

Currently, GitVersion supports:

• TeamCity
• AppVeyor
• Continua

And in the next release MyGet. Jenkins would be a nice addition, but this isn't supported yet.

[serra]

Ah, that's useful info. I'll have a look on how I could do that using Jenkins. Currently I use the command line approach described below the post you linked.

[gep13]

I actually have it on my todo list to look into, but there are quite a few things in front of it, and I actually haven't use Jenkins before, so would be on quite a learning curve :-)

Hopefully it shouldn't be too hard to get set up with someone who is familiar with the system.

Take a look at the recent pull request #289 to add MyGet support, and also at the current implementations for:

• AppVeyor
• ContinuaCI
• TeamCity

Let us know if you have any questions.