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.