Ending up with non-semver semver in 6.0-beta2 #3609
-
Describe the bug Expected Behavior0.6-preview.1 as generated semver Actual Behavior0.0.0-0-6-preview.1 Possible FixNo idea Steps to ReproduceThe following is my gitversion: assembly-versioning-scheme: MajorMinorPatch The Azure Devops looks like: Starting: GitVersion ExecuteTask : Execute GitVersion Task
|
Beta Was this translation helpful? Give feedback.
Replies: 3 comments 1 reply
-
Hi there. I'm going to move this issue to the Question/Answer section because the description seems to me not a bug report. |
Beta Was this translation helpful? Give feedback.
-
From my understanding git version does exactly what you have specified. You are ending up with this semantic version because:
Customizing workflows is a task which should be only an option if you have advanced experience with git version. For the beginning I would recommend you to use the standard supported git hub or git flow workflow: https://gitversion.net/docs/learn/branching-strategies/gitflow/examples Happy branching! Edit: BTW the value 0.0.0-0-6-preview.1 is a valid semantic version |
Beta Was this translation helpful? Give feedback.
-
Still a bugt . I do not say yo uayre wrong - I am saying that if there is a strict semver and you do not find it, there should be an entry in the log that is easy to see. I am so stuck it is not fun, and I can imagine I am the only one. Ok, I got a little further, but the way this system insists on bothing up the version numbers is not fun.
This looks good. It finds 0.1.0 - AMAZING. Except then I read.... Executing GenerateBuildLogOutput for 'AzurePipelines'. See the full sever? Somehow "AssemblySemFileVer": "0.1.0.0", leads to... "FullSemVer": "0.1.0-v0-1-0.1+0", Ok, there is no easy documentation for 6.0 (yet - get that), but thi is close to frustrating. I would have expected that to result in a 0.1.1 versoin number WITHOUT the repeat. |
Beta Was this translation helpful? Give feedback.
From my understanding git version does exactly what you have specified. You are ending up with this semantic version because:
Customizing workflows is a task which should be only an option if you have advanced experience with git version. For the beginning I would recommend you to use the standard supported git hub or git flow workflow: https://gitversion.net/docs/learn/branching-strategies/gitflow/examples
Happy branching!
Edit:
{major}. -> 0.
{minor}. -> 0.
{patch}- -> 0-
{pre-release-label}. -> 0-6-preview.
…