[Bug] tag-prefix still seems to be optionally considered

[andyfurniss4]

Describe the bug
After the changes made in #3216 , I was expecting my issue with tag-prefix to be fixed but that doesn't seem to have happened. The scenario is that I am working in a repo which already has some semver tags which are used to version an API. The format of these tags are like so:

• 2.9.0
• 2.8.0
• 2.7.0
• etc

We want to create an SDK Nuget package which we want to version independently.

Expected Behavior / Actual Behavior

I thought #3216 would allow me to specify a tag-prefix in my GitVersion.yml for my SDK version, meaning the existing tags would be ignored and GitVersion would fall back to counting the commits on the main branch, resulting in an initial version of 0.1.X. However, after specifying a tag-prefix of [vV], it's still picking up the existing tags and determining the next version as 2.9.X.

Steps to Reproduce

gitversion.yml

mode: Mainline
tag-prefix: '[vV]'
branches:
  main: {}
ignore:
  sha: []

Create a bunch of semver tags with no prefix. Run GitVersion. Resulting version is not 0.1.X

Your Environment

Running in a GitHub workflow/action like so:

name: Publish SDK

on:
  push:
    branches: [ "main" ]
  workflow_dispatch:

jobs:
  build:

    runs-on: ubuntu-latest

    steps:
    - uses: actions/checkout@v3
      with:
        fetch-depth: 0
    
    - name: Install GitVersion
      uses: gittools/actions/gitversion/setup@v0.9.15
      with:
        versionSpec: '5.x'
        
    - name: Determine Version
      id: gitversion
      uses: gittools/actions/gitversion/execute@v0.9.15
      with:
        useConfigFile: true
        configFilePath: ./.github/gitversion.yml

• Version Used: 5.11.1
• Operating System and version: Ubuntu 20.04.5

[arturcic]

Hi @andyfurniss4 - that PR was merged in version 5.11.0, but we have reverted it back in 5.11.1 as it was not working as intended
Hopefully @AlexPykavy will have time to rework it. You are using 5.11.1, meaning the PR is not part of the tool

[andyfurniss4]

Ah, I see. I had not noticed the reversion! Thank you for clarifying! Is there an existing issue to track the rework or shall we use this one for that purpose?

[arturcic]

If @AlexPykavy does not mind we can use this one

[andyfurniss4]

Adding a link to rollback issue: #3273

[AlexPykavy]

I've tried to reproduce the #3273 issue but didn't succeed. Then I asked users who encountered the issue for help, but silence... @arturcic, @asbjornu, may I just repeat the same PR but this time to the main branch? I can also note this change somewhere in docs. If you have another thoughts how to reproduce that issue, please share.

[asbjornu]

As we are unable to get @cfauchere or @mglochsen to reply or assist us with testing, I suspect main is a better target for this functionality, yes.

[arturcic]

🎉 This issue has been resolved in version 6.0.0 🎉
The release is available on:

• GitHub Release
• Chocolatey Package
• .Net Global Tool

Your GitReleaseManager bot 📦🚀