How to Ignore a Project Number in the Repo/Branch Name?

[theschnarr]

We have a project numbering system that was used when creating the repo name:
i.e. 1507.03-MY-PROJECT
We're attempting to add GitVersion into our CI process to automate versioning.
Currently, GitVersion says the version is v1507.04.0...
If we pushed a release tag for the master branch, which properly set it to 1.9.0, but any changes since that commit have yielded the v1507.04.0. Is there any configuration that can be used to tell GitVersion to ignore the branch name and fall back to the highest numbered release tag?

[jbaehr]

At a first glance this sounds related to the regex used to dissect the branch name. See #1410 (different context, but maybe somewhat related regarding the root cause)

[PKarasinski-Configit]

We have a similar problem. If a branch is named feature/AA-42.2 then GitVersion produces version number 42.2.0. I get that this is desirable for release branches, but I'd like to know if there is a way to disable it everywhere else (or at least for feature and bugfix branches). And how to do that? Thanks.

[marcwittke]

after migrating to 4.0.0 my version jumped from 1.x somewhat to 20.1.0 Log says:

Base version used: Merge message 'Merge pull request #348 from snip/greenkeeper/babel-jest-20.0.3
chore(package): update babel-jest to version 20.0.3': 20.0.3 with commit count source 7abdf7694554665322e0a4cd4bcad09b5c68159a (Incremented: 20.1.0)

how should i ignore such branch names? I only want to rely on tags...

[gep13]

I believe there are a couple open PR's (this being one of them: #1507 (comment)) that will help with this.

In the meantime, you would be able to exclude the commit that this message is included on in order to return to what you had before.

[PKarasinski-Configit]

I believe there are a couple open PR's (this being one of them: #1507 (comment)) that will help with this.

In the meantime, you would be able to exclude the commit that this message is included on in order to return to what you had before.

That's what we're doing now (excluding commits before a specific date) but yeah, this does not protect us from someone creating such branch and suddenly messing up the build version number (gets worse if it gets merged into develop).

Guess there's nothing more to do but wait for the PR to get accepted and a new version of GitVersion coming out.

[gep13]

If you are willing, you could take the code from the PR branch and test it out in your scenario to make sure that it is working as expected.

[PKarasinski-Configit]

Sure. I'll let you know when I have some time to give it a try.

[derhally]

We are also trying to integrate GitVersion into our build process and it is very common for developers to create branches with numbers. We would prefer that only tags are used to interpret version number.

[PKarasinski-Configit]

We are also trying to integrate GitVersion into our build process and it is very common for developers to create branches with numbers. We would prefer that only tags are used to interpret version number.

@derhally Seems they are working on it, see here and here :).

@gep13 Sorry I never got back to you, it just slipped my mind. But I guess this has been taken care of, so now we just have to wait for new release.

[asbjornu]

This should be fixed by #1541.