[WIP] Branch specific configuration

[JakeGinnivan]

The goal of this PR is to remove the whole branch specific code and to enable a better "branch-configuration". To do this we need basically three things:

• Branch-specific configuration: Done by adding a CurrentBranchConfig property to GitVersionContext
• Implement different version calculation strategies like NextVersionConfigStrategy, MergeMessageVersionStrategy or LastTagVersionStrategy. For all branches the version is then calculated like this

var versionStrategies = new IVersionStrategy[] { new NextVersionConfigStrategy(), new MergeMessageVersionStrategy(), new LastTagVersionStrategy() };
var version = versionStrategies.Select(s => s.CalculateVersion(configuration, branchConfiguration)).Max();

• Implement different variable providers (continous deployment => every commit has different NuGet Version, continous delivery) to enable following code:

var variables = variableProvider.Provide(branchConfiguration.Mode);

Outstanding tasks

• Branch-specific configuration
• Update variable provider
• Fix broken tests
• Legacy configuration error messages
• Documentation - https://github.com/ParticularLabs/GitVersion/wiki/Branch-Specific-Configuration
• 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.

[yannisgu]

@JakeGinnivan the description is kind of outdated. Maybe change it to something like this:

The goal of this PR is to remove the whole branch specific code and to enable a better "branch-configuration". To do this we need basically three things:

• Branch-specific configuration: Done by adding a CurrentBranchConfig property to GitVersionContext
• Implement different version calculation strategies like NextVersionConfigStrategy, MergeMessageVersionStrategy or LastTagVersionStrategy. For all branches the version is then calculated like this

var versionStrategies = new IVersionStrategy[] { new NextVersionConfigStrategy(), new MergeMessageVersionStrategy(), new LastTagVersionStrategy() };
var version = versionStrategies.Select(s => s.CalculateVersion(configuration, branchConfiguration)).Max();

• Implement different variable providers (continous deployment => every commit has different NuGet Version, continous delivery) to enable following code:

var variables = variableProvider.Provide(branchConfiguration.Mode);

[yannisgu]

I started offline with this version finders.. Will try to quickly create a PR

[JakeGinnivan]

No worries.

I have made a start on the variable provider stuff. I think we need to introduce an effective configuration which flattens everything out based on the current branch and apply fallbacks etc. Will give that a spin

[JakeGinnivan]

I think breaking changes are a good idea. Mainly:

• Config file changes. We could migrate like we do now, but could be complex. Maybe we need to introduce a fileVersion or something to the config file so we can version it properly (i.e upgrade to v3 of the config file to light up all these features).
• Removing options from the MSBuild tasks and only support the configuration file.

What do yo think @SimonCropp @andreasohlund

[SimonCropp]

not sure i like putting in a version number into the file. would prefer to gradually add options and give good errors when we obsolete old ones

+1 on removing MSBuild option support

[yannisgu]

This should be really easy to implement: Throw an exception in the old properties of Config and handle them nicely.

[JakeGinnivan]

Am working on another PR which has a legacy config class, reads in everything legacy then provides migration information in a error message.

Sent from my Windows Phone

---

From: yannisgumailto:[email protected]
Sent: ý09/ý01/ý2015 07:59
To: ParticularLabs/GitVersionmailto:[email protected]
Cc: Jake Ginnivanmailto:[email protected]
Subject: Re: [GitVersion] [WIP] Branch specific configuration (#338)

This should be really easy to implement: Throw an exception in the old properties of Config and handle them nicely.

—
Reply to this email directly or view it on GitHubhttps://github.com//pull/338#issuecomment-69304080.

[JakeGinnivan]

Added a wiki page so we can write the doco as we go

https://github.com/ParticularLabs/GitVersion/wiki/Branch-Specific-Configuration

[JakeGinnivan]

@andreasohlund there is one major downside with this approach, it understands merging and reachable versions.

Develop no longer tracks master to bump the version of develop. We also do not have any enforcing if you do GitFlow wrong. I think this is a simpler approach and should work fine.

         *  hotfix-1.2.1       -----------C--      
         *                    /              \     
         *  master           A----------------F-----H-------N
         *                    \                    / \     /
         *  hotfix-1.3.1       \                  /   ----L
         *                      \                /         \
         *  release-1.3.0        \        -D----G---        \
         *                        \      /          \        \
         *  develop                -----B----E-------I-----M--O--P
         *                                    \           /
         *  feature                            -------J-K-

In this case though when release-1.3.0 is merged into master, J used to bump to 1.4.0. This will no longer happen. If you rebase feature then it will bump to 1.4.0 because release-1.3.0 has been merged into develop.

Can you forsee any issues with this?

[andreasohlund]

I can't see any major drawbacks, +1 for proceeding

On Fri, Feb 13, 2015 at 6:09 PM, Jake Ginnivan [email protected]
wrote:

@andreasohlund https://github.com/andreasohlund there is one major
downside with this approach, it understands merging and reachable
versions.

Develop no longer tracks master to bump the version of develop. We also do
not have any enforcing if you do GitFlow wrong. I think this is a simpler
approach and should work fine.

     *  hotfix-1.2.1       -----------C--
     *                    /              \
     *  master           A----------------F-----H-------N
     *                    \                    / \     /
     *  hotfix-1.3.1       \                  /   ----L
     *                      \                /         \
     *  release-1.3.0        \        -D----G---        \
     *                        \      /          \        \
     *  develop                -----B----E-------I-----M--O--P
     *                                    \           /
     *  feature                            -------J-K-

In this case though when release-1.3.0 is merged into master, J used to
bump to 1.4.0. This will no longer happen. If you rebase feature then it
will bump to 1.4.0 because release-1.3.0 has been merged into develop.

Can you forsee any issues with this?

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