WIP: Continuous deployment and delivery versioning mode #325

yannisgu · 2014-12-10T07:52:47Z

As discussed #323 GitVersion should support different versioning modes which can be configured in the GitVersionConfig.yaml.

The modes are continuous deployment and continuous delivery.

As @JakeGinnivan says:

Continuous deployment means you want each build to have a unique nuget version, continuous delivery means you do not.

At the moment the only difference is the pre-release tag. In continuous delivery the scheme is <configured tag>.1 or if there is an applicable tag <last-tag-name>-<last-tag-number>+1.
In continuous deployment the scheme is <configured tag>.<nr of commits>

What is still open:

GitHub flow, how to handle those there?
Feature branches, how is the scheme here?
Are hotfix branches "the same" as release branches?
Support branches?
Maybe find a better place than GitFlowVersionFInder for setting the CurrentBranchConfig property or maybe even find a better place for this property than the context
Do we need more than just the pre-release tag in the versioning mode?
Can code be dropped?

Happy to see your comments and thoughts 😄

robdmoore · 2014-12-10T09:39:09Z

I thought one of the version number variables had number of commits as the fourth build number already?

On 10 Dec 2014, at 3:52 pm, yannisgu [email protected] wrote:

As discussed #323 GitVersion should support different versioning modes which can be configured in the GitVersionConfig.yaml.

The modes are continuous deployment and continuous delivery.

As @JakeGinnivan says:

Continuous deployment means you want each build to have a unique nuget version, continuous delivery means you do not.

At the moment the only difference is the pre-release tag. In continuous delivery the scheme is .1 or if there is an applicable tag -+1.
In continuous deployment the scheme is .

What is still open:

GitHub flow, how to handle those there?
Feature branches, how is the scheme here?
Are hotfix branches "the same" as release branches?
Support branches?
Maybe find a better place than GitFlowVersionFInder for setting the CurrentBranchConfig property or maybe even find a better place for this property than the context
Do we need more than just the pre-release tag in the versioning mode?
Can code be dropped?
Happy to see your comments and thoughts

You can merge this Pull Request by running

git pull https://github.com/unic/GitVersion versioningModes
Or view, comment on, or merge it at:

#325

Commit Summary

Added support for branch specific config
Implemented different versioning modes
File Changes

M GitVersionCore.Tests/ConfigProviderTests.cs (45)
M GitVersionCore.Tests/IntegrationTests/GitFlow/DevelopScenarios.cs (24)
M GitVersionCore.Tests/IntegrationTests/GitFlow/ReleaseBranchTests.cs (19)
A GitVersionCore/Configuration/BranchConfig.cs (13)
M GitVersionCore/Configuration/Config.cs (58)
M GitVersionCore/Configuration/ConfigReader.cs (5)
M GitVersionCore/GitFlow/BranchFinders/DevelopBasedVersionFinderBase.cs (1)
M GitVersionCore/GitFlow/BranchFinders/DevelopVersionFinder.cs (19)
M GitVersionCore/GitFlow/BranchFinders/HotfixVersionFinder.cs (17)
M GitVersionCore/GitFlow/BranchFinders/RecentTagVersionExtractor.cs (6)
M GitVersionCore/GitFlow/BranchFinders/ReleaseVersionFinder.cs (2)
M GitVersionCore/GitFlow/GitFlowVersionFinder.cs (3)
M GitVersionCore/GitHubFlow/OtherBranchVersionFinder.cs (2)
M GitVersionCore/GitVersionContext.cs (2)
M GitVersionCore/GitVersionCore.csproj (5)
A GitVersionCore/VersioningModes/ContinuousDeliveryMode.cs (15)
A GitVersionCore/VersioningModes/ContinuousDeploymentMode.cs (14)
A GitVersionCore/VersioningModes/VersioningMode.cs (28)
A GitVersionCore/VersioningModes/VersioningModeBase.cs (11)
Patch Links:

https://github.com/ParticularLabs/GitVersion/pull/325.patch
https://github.com/ParticularLabs/GitVersion/pull/325.diff
—
Reply to this email directly or view it on GitHub.

JakeGinnivan · 2014-12-10T10:04:05Z

@robdmoore they do, but say I want release branches to do that and master to have proper semver, now my build scripts need to know what branch I am on. Configuration seems the right place for this

robdmoore · 2014-12-10T10:06:57Z

Yep, agreed for that scenario :)

On 10 Dec 2014, at 6:04 pm, Jake Ginnivan [email protected] wrote:

@robdmoore they do, but say I want release branches to do that and master to have proper semver, now my build scripts need to know what branch I am on. Configuration seems the right place for this

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

JakeGinnivan · 2014-12-10T10:15:40Z

@yannisgu Looking at this, we need to change the yaml.

Maybe:

branches:
   - # release/
     prefix: release[/-]
     tag: rc
     mode: continuousdelivery
   - # develop
     prefix: develop$
     tag: alpha
     mode: continuousdelivery

Then on the Config we have:

class Config
{
    public List<BranchConfig> Branches {get;set;}
}

class BranchConfig
{
     public string Prefix { get;set;}
     public string tag {get;set;}
     public Mode Mode {get;set;}
}

yannisgu · 2014-12-10T12:46:03Z

@JakeGinnivan yep I see, we need to be more flexible.

Is your goal to completly abstract away the "version finders"? So that there would only be one branch finder which calculates the version depending on the matching branch configuration? Then there would be one big default configuration for each branch, which reflects the current behavior?

JakeGinnivan · 2014-12-10T14:13:43Z

@yannisgu yep exactly right.

My idea is that we have a bunch of version strategies, then configuration. So the main version calculation function would be:

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

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

In my head this would work. But have not actually spiked it out to see if my simplistic view would actually work.

JakeGinnivan · 2014-12-10T14:16:04Z

And branchCOnfiguration would be simply:

//List<BranchConfig> branchesConfig;

branchesConfig.FirstOrDefault(b => Regex.IsMatch(branchName, b.Prefix);

And we populate the list with defaults, overriding values which have been specified in config

yannisgu · 2014-12-10T15:27:13Z

Okey I see. This sounds like a lot of refactoring 😄

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

Hmm is the mode-handling really in the variable provider?

yannisgu · 2014-12-10T16:03:18Z

Instead of a list I think a dictionary is better for the branches key: https://github.com/ParticularLabs/GitVersion/pull/325/files#diff-5779d04f6f560a78b6aef819b4288a9aR71

JakeGinnivan · 2014-12-10T17:02:51Z

Hmm is the mode-handling really in the variable provider?

The semver either way is <major>.<minor>.<patch>-<tag>+<buildmetadata>, ToString has different formatting options which will output that as <major>.<minor>.<patch>-<tag>+<buildmetadata> or <major>.<minor>.<patch>.<buildmetadata>-<tag>. So yeah it will end up in variable provider.

Also, variables like SemVer will always stay as the SemVer. it is things like NuGet version etc that will be affected.

Instead of a list I think a dictionary is better for the branches key: https://github.com/ParticularLabs/GitVersion/pull/325/files#diff-5779d04f6f560a78b6aef819b4288a9aR71

The branch prefix is a regex, we should append $ so it starts at the beginning of the line, but yeah we need to run matches so a dictionary won't help.

orjan · 2014-12-17T13:56:42Z

Given a branch "feature/BRIKKS-1337" GitVersion (GitFlow) will generate a PreReleaseTag with:
Name: BRIKKS-
Number: 1337

with a broken output:
"LegacySemVerPadded":"1.1.0-BRIKKS1337",
"FullSemVer":"1.1.0-BRIKKS-.1337+1",

I'll guess this PR will handle the case above?

JakeGinnivan · 2014-12-17T15:07:28Z

@orjan A pr and a test showing the new behaviour would be awesome.

Thanks

orjan · 2014-12-18T22:08:56Z

@JakeGinnivan I've submitted a PR trying to explain my issue:
#327

JakeGinnivan · 2015-01-07T16:21:08Z

@yannisgu moving to #338 which is a branch in the main repo, so we can all submit PR's to this effort. This is a great start

Yannis Guedel added 3 commits December 9, 2014 15:51

Added support for branch specific config

62c532d

Implemented different versioning modes

36c87a8

code cleanup

ab38fd3

changed branches

2c47502

enhanced branches config

c2330e4

orjan mentioned this pull request Jan 6, 2015

Feature branch with jira key #337

Merged

JakeGinnivan mentioned this pull request Jan 7, 2015

[WIP] Branch specific configuration #338

Closed

7 tasks

JakeGinnivan closed this Jan 7, 2015

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

WIP: Continuous deployment and delivery versioning mode #325

WIP: Continuous deployment and delivery versioning mode #325

Uh oh!

yannisgu commented Dec 10, 2014

Uh oh!

robdmoore commented Dec 10, 2014

Uh oh!

JakeGinnivan commented Dec 10, 2014

Uh oh!

robdmoore commented Dec 10, 2014

Uh oh!

JakeGinnivan commented Dec 10, 2014

Uh oh!

yannisgu commented Dec 10, 2014

Uh oh!

JakeGinnivan commented Dec 10, 2014

Uh oh!

JakeGinnivan commented Dec 10, 2014

Uh oh!

yannisgu commented Dec 10, 2014

Uh oh!

yannisgu commented Dec 10, 2014

Uh oh!

JakeGinnivan commented Dec 10, 2014

Uh oh!

orjan commented Dec 17, 2014

Uh oh!

JakeGinnivan commented Dec 17, 2014

Uh oh!

orjan commented Dec 18, 2014

Uh oh!

JakeGinnivan commented Jan 7, 2015

Uh oh!

Uh oh!

WIP: Continuous deployment and delivery versioning mode #325

WIP: Continuous deployment and delivery versioning mode #325

Uh oh!

Conversation

yannisgu commented Dec 10, 2014

Uh oh!

robdmoore commented Dec 10, 2014

Uh oh!

JakeGinnivan commented Dec 10, 2014

Uh oh!

robdmoore commented Dec 10, 2014

Uh oh!

JakeGinnivan commented Dec 10, 2014

Uh oh!

yannisgu commented Dec 10, 2014

Uh oh!

JakeGinnivan commented Dec 10, 2014

Uh oh!

JakeGinnivan commented Dec 10, 2014

Uh oh!

yannisgu commented Dec 10, 2014

Uh oh!

yannisgu commented Dec 10, 2014

Uh oh!

JakeGinnivan commented Dec 10, 2014

Uh oh!

orjan commented Dec 17, 2014

Uh oh!

JakeGinnivan commented Dec 17, 2014

Uh oh!

orjan commented Dec 18, 2014

Uh oh!

JakeGinnivan commented Jan 7, 2015

Uh oh!

Uh oh!