New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[WIP] Branch specific configuration #338

Closed
wants to merge 78 commits into
base: master
from

Conversation

Projects
None yet
6 participants
@JakeGinnivan
Contributor

JakeGinnivan commented Jan 7, 2015

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

This comment has been minimized.

Show comment
Hide comment
@yannisgu

yannisgu Jan 8, 2015

Contributor

@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);
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

This comment has been minimized.

Show comment
Hide comment
@yannisgu

yannisgu Jan 8, 2015

Contributor

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

Contributor

yannisgu commented Jan 8, 2015

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

@JakeGinnivan

This comment has been minimized.

Show comment
Hide comment
@JakeGinnivan

JakeGinnivan Jan 8, 2015

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

Contributor

JakeGinnivan commented Jan 8, 2015

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

This comment has been minimized.

Show comment
Hide comment
@JakeGinnivan

JakeGinnivan Jan 8, 2015

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

Contributor

JakeGinnivan commented Jan 8, 2015

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

This comment has been minimized.

Show comment
Hide comment
@SimonCropp

SimonCropp Jan 8, 2015

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

Contributor

SimonCropp commented Jan 8, 2015

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 comment has been minimized.

Show comment
Hide comment
@yannisgu

yannisgu Jan 9, 2015

Contributor

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

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

This comment has been minimized.

Show comment
Hide comment
@JakeGinnivan

JakeGinnivan Jan 9, 2015

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.

Contributor

JakeGinnivan commented Jan 9, 2015

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

This comment has been minimized.

Show comment
Hide comment
@JakeGinnivan

JakeGinnivan Jan 9, 2015

Contributor

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

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

Contributor

JakeGinnivan commented Jan 9, 2015

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

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

@JakeGinnivan

This comment has been minimized.

Show comment
Hide comment
@JakeGinnivan

JakeGinnivan Jan 10, 2015

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

Contributor

JakeGinnivan commented Jan 10, 2015

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

This comment has been minimized.

Show comment
Hide comment
@JakeGinnivan

JakeGinnivan Jan 10, 2015

Contributor

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

Contributor

JakeGinnivan commented Jan 10, 2015

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

@andreasohlund

This comment has been minimized.

Show comment
Hide comment
@andreasohlund

andreasohlund Jan 10, 2015

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)
.

Contributor

andreasohlund commented Jan 10, 2015

+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

This comment has been minimized.

Show comment
Hide comment
@JakeGinnivan

JakeGinnivan Jan 10, 2015

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

Contributor

JakeGinnivan commented Jan 10, 2015

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

Show outdated Hide outdated BREAKING CHANGES.md
@@ -0,0 +1,5 @@
v3.0.0
- `AssemblyFileSemVer` variable removed, AssemblyVersioningScheme configuration value makes this variable obsoluete

This comment has been minimized.

@SimonCropp

SimonCropp Jan 17, 2015

Contributor

obsoluete

@SimonCropp

SimonCropp Jan 17, 2015

Contributor

obsoluete

@JakeGinnivan

This comment has been minimized.

Show comment
Hide comment
@JakeGinnivan

JakeGinnivan Feb 13, 2015

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?

Contributor

JakeGinnivan commented Feb 13, 2015

@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

This comment has been minimized.

Show comment
Hide comment
@andreasohlund

andreasohlund Feb 13, 2015

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)
.

Contributor

andreasohlund commented Feb 13, 2015

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

This comment has been minimized.

Show comment
Hide comment
@SimonCropp

SimonCropp Feb 15, 2015

Contributor

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

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

This comment has been minimized.

Show comment
Hide comment
@JakeGinnivan

JakeGinnivan Feb 15, 2015

Contributor

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

Contributor

JakeGinnivan replied Feb 15, 2015

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

This comment has been minimized.

Show comment
Hide comment
@JakeGinnivan

JakeGinnivan Feb 15, 2015

Contributor

Just pushed a commit which fixed 3 instances of this

Contributor

JakeGinnivan replied Feb 15, 2015

Just pushed a commit which fixed 3 instances of this

This comment has been minimized.

Show comment
Hide comment
@SimonCropp

SimonCropp Feb 15, 2015

Contributor

@nulltoken shouldnt PeeledTarget be something included in libgit?

Contributor

SimonCropp replied Feb 15, 2015

@nulltoken shouldnt PeeledTarget be something included in libgit?

This comment has been minimized.

Show comment
Hide comment
@SimonCropp

SimonCropp Feb 15, 2015

Contributor

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

Contributor

SimonCropp replied Feb 15, 2015

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

This comment has been minimized.

Show comment
Hide comment
@JakeGinnivan

JakeGinnivan Feb 15, 2015

Contributor

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

Contributor

JakeGinnivan replied Feb 15, 2015

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

This comment has been minimized.

Show comment
Hide comment
@nulltoken

nulltoken Feb 15, 2015

Contributor

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

Contributor

nulltoken replied Feb 15, 2015

@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