Release/3.0.0

[JakeGinnivan]

Creating release branch for 3.0.0 release.

TODO:

• Documentation - https://github.com/ParticularLabs/GitVersion/wiki/Branch-Specific-Configuration (readme updated)
• Discuss: continuous deployment 4 part stable version not including 4th part if it is 0
• Add useBranchNameAsTag rather than using "useBranchName" magic string. useBranchNameAsTag being true should cause the tag setting to be ignored. (Not going to fix)
• Put together breaking changes list
• Add /showConfig flag to print out effective configuration
• VersioningMode at branch level should override global level
• Do not put build metadata number for continuous deployment mode

[JakeGinnivan]

@orjan @GeertvanHorrik I have fixed the issues around commit counting and the develop branch which you both spotted. Could you have another look

[orjan]

I've been doing some regression and our develop branch won't bump when master merges develop.

I'll guess it the breaking change that I'm seeing?
"v3.0.0 - Develop no longer tracks master"

If this is intended what's the workarounds? Manually bumping the config file or creating a release branch?

[Test]
    public void ShouldBumpDevelopWhenBeeingMergeBackIntoMaster()
    {
        using (var fixture = new EmptyRepositoryFixture(
            new Config { VersioningMode = VersioningMode.ContinuousDeployment} )
        )
        {
            fixture.Repository.MakeATaggedCommit("1.0.0");
            fixture.Repository.CreateBranch("develop").Checkout();
            fixture.Repository.MakeCommits(3);
            fixture.AssertFullSemver("1.1.0-unstable.3");

            fixture.Repository.Branches["master"].Checkout();
            fixture.Repository.MergeNoFF("develop");
            fixture.Repository.ApplyTag("1.1.0");

            fixture.Repository.Branches["develop"].Checkout();
            fixture.Repository.MakeACommit();
            fixture.AssertFullSemver("1.2.0-unstable.1");

            /* Current test output
                should be
                    "1.2.0-unstable.1"
                but was
                    "1.1.0-unstable.4"
            */
        }
    }

[orjan]

I have a similar issue with feature branches where the commits in the develop branch counts as commits for the feature, not sure if this is intended?

    [Test]
    public void FeatureBranchShouldNotKeepCountingCommitsFromDevelop()
    {
        using (var fixture = new EmptyRepositoryFixture(
            new Config { VersioningMode = VersioningMode.ContinuousDeployment} )
        )
        {
            fixture.Repository.MakeATaggedCommit("1.0.0");

            fixture.Repository.CreateBranch("develop").Checkout();
            fixture.Repository.MakeCommits(3);
            fixture.AssertFullSemver("1.1.0-unstable.3");

            fixture.Repository.CreateBranch("feature/foo").Checkout();
            fixture.Repository.MakeACommit();

            fixture.AssertFullSemver("1.1.0-foo.1");

            /*
                should be
                    "1.1.0-foo.1"
                but was
                    "1.1.0-foo.4"
             */
        }
    }

[JakeGinnivan]

For your first scenario we could introduce a new config which is tracking-branch which would be used for develop to track master. That would be a base version calculator which would find masters version at that time.

For the second, commit counting is done from the source of the base version. In this case the commit that develop last bumped it's version. We could also calculate from the branch point and take the lesser of the two?

Pull request for either of those are welcome :) For me not show stoppers. @andreasohlund is the first issue a problem for you?

[andreasohlund]

No issue for us since we don't really care about commit counting on develop

[orjan]

@JakeGinnivan no show stoppers for us, since the counter is increasing.

[JakeGinnivan]

@orjan feel free to create issues for either of those things to discuss separately.

@andreasohlund should we press the button on beta.1

[andreasohlund]

+1 For beta (let me double check the fileversion bug first)

On Wed, Feb 18, 2015 at 2:34 PM, Jake Ginnivan [email protected]
wrote:

@orjan https://github.com/orjan feel free to create issues for either
of those things to discuss separately.

@andreasohlund https://github.com/andreasohlund should we press the
button on beta.1

—
Reply to this email directly or view it on GitHub
#364 (comment)
.

[orjan]

Will create issue, has spiking a little bit to understand more about the code base.

Do we have a clue how many installations that will auto update gitversion when 3.0 is released? E.g TeamCity meta runner with auto update enabled.

On 18 feb 2015, at 14:34, Jake Ginnivan [email protected] wrote:

@orjan feel free to create issues for either of those things to discuss separately.

@andreasohlund should we press the button on beta.1

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