[WIP] Branch specific configuration #338

Closed
wants to merge 78 commits into
from

Projects

None yet

6 participants

@JakeGinnivan
Contributor

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.
@JakeGinnivan JakeGinnivan referenced this pull request Jan 7, 2015
Closed

WIP: Continuous deployment and delivery versioning mode #325

0 of 7 tasks complete
@yannisgu
Contributor
yannisgu commented Jan 8, 2015

@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
Contributor
yannisgu commented Jan 8, 2015

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

@JakeGinnivan
Contributor

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
Contributor

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
Contributor

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
Contributor
yannisgu commented Jan 9, 2015

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

@JakeGinnivan
Contributor

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:notifications@github.com
Sent: ý09/ý01/ý2015 07:59
To: ParticularLabs/GitVersionmailto:GitVersion@noreply.github.com
Cc: Jake Ginnivanmailto:jake@ginnivan.net
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/ParticularLabs/GitVersion/pull/338#issuecomment-69304080.

@JakeGinnivan
Contributor

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

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

@JakeGinnivan
Contributor

I propose getting rid of ClassicVersion and maybe AssemblyFileSemVer (we have config to change what is included in the assembly version, lets just have a single variable). Thoughts @SimonCropp @andreasohlund

@JakeGinnivan
Contributor

BTW, I think this will be v3. So I am ok with breaking changes

@andreasohlund
Contributor

+1 for removing them

On Sat, Jan 10, 2015 at 5:07 PM, Jake Ginnivan notifications@github.com
wrote:

BTW, I think this will be v3. So I am ok with breaking changes


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

@JakeGinnivan
Contributor

Ok, I have been putting some thought into how this could work. Here is my current thinking of new architecture. Everything is generated using http://www.plantuml.com/plantuml, I will include source and the png.

Version Calculation

image

database Config

NextVersionCalculator -> BaseVersionCalculator: GetBaseVersion
note right: see below for how base is calculated
BaseVersionCalculator -> NextVersionCalculator: 2.0.0|25e4ba

Config -> NextVersionCalculator: Branch increment strategy (patch)

alt base version has pre-release tag
    NextVersionCalculator -> NextVersionCalculator: Increment the number on the tag
else 
    Config -> NextVersionCalculator: pre-release tag for current branch (alpha)
    NextVersionCalculator -> NextVersionCalculator: Increment using correct strategy: 2.0.1
    NextVersionCalculator -> NextVersionCalculator: 2.0.1-alpha.1
end

NextVersionCalculator -> CommitCounter: 25e4ba | current branch
note right
     Calculate number of commits since 
     timestamp of 25e4ba on current branch
end note
CommitCounter -> NextVersionCalculator: 10

NextVersionCalculator -> BuildMetadataCreator: 10 | Context
BuildMetadataCreator -> NextVersionCalculator: 10.branch.develop.sha.5e42ba

NextVersionCalculator -> NextVersionCalculator: 2.0.1-alpha.1+10

Base Version Calculation

image

NextVersionCalculator -> BaseVersionCalculator: GetBaseVersion
BaseVersionCalculator -> ConfigNextVersionBaseVersion: GetVersion
BaseVersionCalculator -> MergeMessageBaseVersion: GetVersion
BaseVersionCalculator -> LastTagBaseVersion: GetVersion
BaseVersionCalculator -> ReferenceBranchTagBaseVersion: GetVersion
ConfigNextVersionBaseVersion -> BaseVersionCalculator: -
MergeMessageBaseVersion -> BaseVersionCalculator: 2.0.0|25e4ba
LastTagBaseVersion -> BaseVersionCalculator: 2.0.0-beta.2|bec75d (from release branch)
ReferenceBranchTagBaseVersion -> BaseVersionCalculator: 1.9.0|a2c1e3 (reference branch is master)
BaseVersionCalculator -> BaseVersionCalculator: Max of BaseVersion calculation strategies
BaseVersionCalculator -> NextVersionCalculator: 2.0.0|25e4ba

I am going to have a crack to see if this will actually work out and wanted to draw out what I had in my head before coding it. If you see any major issues shout, otherwise I will let you know how I go

@yannisgu
Contributor

In continous deployment mode, if the version is not a pre-release the SemVer contains 4 digits: Major.Minor.Path.Commits. In my opinion if the commits number is 0 (which is the normal case in GitFlow), it should not be included, are there any thoughts about it?

JakeGinnivan added some commits Jan 11, 2015
@JakeGinnivan JakeGinnivan Deprecated NextVersion.txt ea0e316
@JakeGinnivan JakeGinnivan Merge pull request #345 from JakeGinnivan/NoMoreNextVersionTxt
Deprecated NextVersion.txt
7b59651
@JakeGinnivan JakeGinnivan Starting on base version calculators f85cd83
@JakeGinnivan JakeGinnivan Added merge message base version strategy 62b6f42
@JakeGinnivan JakeGinnivan Adding LastTagBaseVersionStrategy b25220a
@JakeGinnivan JakeGinnivan Created NewNextVersionCalculator which is the new version calculation 8ee25e8
@JakeGinnivan JakeGinnivan Added MetaDataCalculator in and fixed up some other shortcomings in t…
…he design
a74bbf5
@JakeGinnivan JakeGinnivan Uncomment line in GitVersionFinder to test new way of doing things. I…
…t kinda works but lots of small differences causing test breaks
aa54a21
@JakeGinnivan JakeGinnivan Should not increment version when current commit is tagged 7a0267f
@JakeGinnivan JakeGinnivan Added missing base version finder 83d3862
@JakeGinnivan JakeGinnivan Allow inheriting of the parent branches increment strategy. Allows fe…
…ature branches off develop or master to increment based off the develop or master increment strategy
a952bb1
@JakeGinnivan JakeGinnivan When branch configuration has 'Tag' set to 'useBranchName' it will us…
…e the branch name to create the tag
690399e
@JakeGinnivan JakeGinnivan Fixed a few tests and the way inheriting increment strategy works 810d309
@JakeGinnivan JakeGinnivan Base versions can specify whether the tag should be updated 3e0be76
@JakeGinnivan JakeGinnivan Fixing incorrect tests, when develop is branched from master it is st…
…ill a tagged commit. The version should not change
2dbcc84
@JakeGinnivan JakeGinnivan Fixed some exceptions which were causing tests to blow up and not get…
… a result
204d2bc
@JakeGinnivan JakeGinnivan Think the code is mostly there. It is now mainly fixing commit counti…
…ng and different test scenarios
e999a62
@JakeGinnivan JakeGinnivan Fixed failing tests 900ccf6
@JakeGinnivan JakeGinnivan Fixed build issue 8ab088f
@SimonCropp SimonCropp commented on an outdated diff Jan 17, 2015
BREAKING CHANGES.md
@@ -0,0 +1,5 @@
+v3.0.0
+ - `AssemblyFileSemVer` variable removed, AssemblyVersioningScheme configuration value makes this variable obsoluete
@SimonCropp
SimonCropp Jan 17, 2015 Contributor

obsoluete

@JakeGinnivan
Contributor

@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
Contributor

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

On Fri, Feb 13, 2015 at 6:09 PM, Jake Ginnivan notifications@github.com
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)
.

@JakeGinnivan JakeGinnivan deleted the BranchSpecificConfiguration branch Feb 13, 2015
@SimonCropp

Should this be t.PeeledTarget() instead of t.Target

Contributor

I only noticed that in something.. Will do a find/replace...

Contributor

Just pushed a commit which fixed 3 instances of this

Contributor

@nulltoken shouldnt PeeledTarget be something included in libgit?

Contributor

@JakeGinnivan i actually asked rather then doing a commit since i wasnt sure :)

Contributor

I'm not sure either, but it doesn't look like it would hurt :P

Contributor

@bording is working on making this happen (see libgit2/libgit2sharp#551) 😉

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment