support for other names for tags and develop branch

[PeterLehmann]

I do like this tool, so version info is keep in git, but on this project has a other naming conv. for tags and develop branch, so we fail back to githubflow and gitflow(what are are runnign with some diff.).
so we will be lovy that you can define what prefix version tags has e.g. version-{x.y.z}
and or what the name for main develop branch is called.
i don't knwon if config or passing it into task/command is the best way.

[JakeGinnivan]

Config definitely. The issue is the .exe does not support config files yet.

Something like:

tagPrefix: version-

This will be stripped before using the tag

[PeterLehmann]

yes something like that.
but if config, i think somthing like a .gitversion file at root of the project with overrides for default behaver.
this way i think it will be easy for both cmd and task to use the samme overrides.

[gep13]

I think this will end up being linked to this #277

Which started with the work done here #256

i.e. add the suggested tagPrefix: version- into the GitVersionConfig.yaml file. which is used by the task.

[asbjornu]

I too would like this. As I mention in #283, our develop branch is called development and we don't do release branches. Having GitVersion support that sort of repository layout would be awesome.

[gep13]

I think that this is something that we could add to the *.yaml file, in the same way that this can be specified in something like Stash:

[asbjornu]

Yes, @gep13, that looks perfect! Even better: Being able to specify templates (not just prefixes) for every configurable branch type. That would completely cover all requirements I mention in #283, I think. This is how I imagine a default GitVersionConfig.yaml might look like:

branch-layout:
    development:
        name: develop
        version: {major}.{minor}.{patch + 1}-unstable{buildmetadata}
    production:
        name: master
        version: {major}.{minor + 1}.{patch + 1}.{buildmetadata}
    bugfix:
        name: bugfix/*
        version: {major}.{minor}.{patch + 1}-bugfix{buildmetadata}
    feature:
        name: feature/*
        version: {major}.{minor}.{patch + 1}-bugfix{buildmetadata}
    hotfix:
        name: hotfix/*
        version: {major}.{minor}.{patch + 1}-hotfix{buildmetadata}
    release:
        name: release/*
        version: {major}.{minor + 1}.{patch + 1}.{buildmetadata}

[JakeGinnivan]

Ok, so #302 will support tag-prefix, but unsure about the rest. @asbjornu I want your feedback.

If you do not have develop branch then we support NextVersion.txt (soon this will move into GitVersionConfig.yaml) as well as automatically tagging the version with the branch name. For example hotfix/ will end up with a version of 1.2.3-hotfix.5. We also will allow overriding develop and release tags (which based on what you say does not affect you at all).

What I am trying to understand is the exact issue that level of configuration will fix for you?

[gep13]

@JakeGinnivan The way I understood part of this was to do with this:

https://github.com/ParticularLabs/GitVersion/blob/master/GitVersionCore/GitFlow/BranchClassifier.cs#L20

@asbjornu has the concept of a develop branch, but doesn't actually have a branch called develop, rather one that is called development. Right now, the branch classifier doesn't work for him. If instead, it was possible to specify the branch names in the config file, the BranchClassifier could use that, instead of the hardcoded "develop"

[JakeGinnivan]

So add develop-branch-name to config file and we are good?

[gep13]

So add develop-branch-name to config file and we are good?

There might be other things, so we will need to wait for @asbjornu to confirm, but this was at least one of the main issues that was seen.

[asbjornu]

Yes, our development branch isn't called develop, but development. So being able to configure the name like I propose in the YAML example, would probably help a lot. We also don't use hotfix or release branches, we just have master, development and unprefixed feature branches.

[SimonCropp]

@asbjornu why cant you rename your branch to be "develop"?

[SimonCropp]

TBH i am not sure this is a good idea. gitflow says it should be "develop" what is the value in us adding complexity to make it configurable.

[gep13]

From my point of view, GitFlow makes a recommendation to name your branch develop, but that is what it is, a recommendation. As shown above, tools like SourceTree allow you to specify additional configuration to match naming conventions of branches, so personally I think we should do the same here with GitVersion. Just my 2 cents....

[SimonCropp]

i am a -1 for fixing this. gitflow does not "make a recommendation to use develop" it says "the branch will be named develop"

The central repo holds two main branches with an infinite lifetime: master and develop

I think making branch conventions configurable adds unnecessary complexity in terms of testing, implementation and documentation.

If people want to run a custom implementation of gitflow then they can use a modified fork of gitversion.

[asbjornu]

Our internal workflow was created before we discovered GitFlow or before GitFlow was created, that's why the development branch is called development and not develop. As @PeterLehmann also has a need to configure the name of the development branch, there's reason to believe he and I aren't alone. Also, if you're going to make one of the branch names (prefix or otherwise) configurable, I think making all of them configurable would be good for completeness (and if you do #305, also good for documentation).

I can't say anything about the complexity of implementing and maintaining this, since I don't know the GitVersion codebase good enough, but I think it's safe to say that people who don't follow GitFlow or GitHubFlow knows that they are the deviators and don't necessarily expect everything to be smooth sailing. However, having some support for the deviation in GitVersion would help tremendously.

[JakeGinnivan]

Thinking about this, I am kinda in agreement with Simon.

It is a slippery slope. The more config options we have the more complex our doco will be. I think master, release, support and hotfix should never be configurable.

The thing is that develop has very specific behavior and enables GitFlow support which is restricted in the workflows it supports.

So, do we allow develop to be configurable which diverges from GitFlow meaning more docs, or just recommend that everyone renames their custom develop branch to develop to fix the workflow?

What are the blockers for renaming the branch?

[JakeGinnivan]

Also, @PeterLehmann needs support for custom tag prefixes. That is quite different. Tags are part of your history and a repositories legacy. Supporting it prefixed with version- or v or anything else I think is fine as it is not specified anywhere in git workflows.

[PeterLehmann]

version tags cannot just as easy be changes, the problem is not that big
for branches other then you need to get all to using a new branch naming
convention.
to add new tags and get the oldd ones deleted i git, you need to get each
developer on the team to run a script

On Tue, Nov 18, 2014 at 12:22 PM, Jake Ginnivan [email protected]
wrote:

Also, @PeterLehmann https://github.com/PeterLehmann needs support for
custom tag prefixes. That is quite different. Tags are part of your history
and a repositories legacy. Supporting it prefixed with version- or v or
anything else I think is fine as it is not specified anywhere.

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

[asbjornu]

I understand. But as I wrote in #283, the current implementation makes it really hard to find out what GitVersion is doing and why. It's still a mystery to me why branches other than master gets a NuGetVersionV2 version string that does not contain unstable or similar strings that make it a prerelease NuGet package.

The current implementation not only requires us to rename all development branches to develop across all our repositories, it also requires us to set up two build configurations per repository in TeamCity; one for stable releases and one for pre-releases. If at least one of those problems could be solved, I'd be very happy. 😄

[JakeGinnivan]

Ok cool

I am going to close this issue, then can focus on #283 in isolation. And will respond to that particular issue there.

[JakeGinnivan]

Closed via #302

[gep13]

One thing that I will just throw into the mix (yes, I realise that this could be stirring up trouble)....

If you have a look here:

http://alblue.bandlem.com/2011/11/git-tip-of-week-git-flow.html

You will see the git-flow extensions described. When you do:

git flow init

it prompts you to say what each branch is named, and supporting branch is named. The git-flow extensions are hosted here:

https://github.com/nvie/gitflow

Which I believe are a direct implementation of the git flow strategy which is documented here:

http://nvie.com/posts/a-successful-git-branching-model/

So although the recommendation seems to be to use develop/master, etc, the existing tooling allow you to use something other.

Thoughts?

[JakeGinnivan]

I am not against adding it later. There is just more useful configuration we can add now

[SimonCropp]

@gep13 still not sold :)

[SimonCropp]

Damn. seems everyone has already let the cat out of the bag. sourcetree also supports custom branch naming when u "enable a repo to be gitflow".

So i think i need to reverse my -1 :(

[JakeGinnivan]

:( Lets get v2 out with more important configuration then go from there

[gep13]

sourcetree also supports custom branch naming

Isn't that the same screenshot I showed here:

#292 (comment)

:-)

[SimonCropp]

@gep13 was hoping that was the one tool that had gone the complex route. But it seems everyone has. So I guess it is a case of don't fight it.

[asbjornu]

SmartGit has the same configuration dialog:

[JakeGinnivan]

This is fully supported in 3.0.

Phew.. that was a lot of work...

[asbjornu]

Great work! Exactly how is this supported? Via .yml configuration?

[JakeGinnivan]

Yep, via the config. You can use 'GitVersion init' to generate a sample config file or 'gitversion /showConfig' to see the effective config and just override what you want to.

Sent from my Windows Phone

---

From: Asbjørn Ulsbergmailto:[email protected]
Sent: ‎26/‎02/‎2015 04:07
To: ParticularLabs/GitVersionmailto:[email protected]
Cc: Jake Ginnivanmailto:[email protected]
Subject: Re: [GitVersion] support for other names for tags and develop branch (#292)

Great work! Exactly how is this supported? Via .yml configuration?

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/292#issuecomment-76144232.