Asbjørn Ulsberg

Yeah, that may explain the problem in the unit test, but not in the released executable. I have a Homebrew-installed GitVersion version `5.6.10` that returns `1.0.0`: ```sh $ gitversion -version...

I just tested with GitVersion `5.8.2` and it has the same discrepancy between the Homebrew and .NET Tool version: ```sh $ gitversion -version 1.0.0 ``` ```sh $ dotnet gitversion -version...

After merging `release` branches, you need to add a tag to `master`. Since the `release` branch will most likely be deleted after it is merged, it can't be used as...

This is a great suggestion, but I think, unfortunately, it points to the need for GitVersion to do less. Having to change GitVersion in order to have the AzDO Task...

`feature/*` branches should be created from `develop`, not from a `release/*` branch. If you change that, I think you'll get more of the inteded behaviour.

Yes, or by merging more `feature/*` branches into `develop` and then rebasing the `release/*` branch on `develop` or merging `develop` into the `release/*` branch.

Sure, I understand that. But I don't see a way to tell GitVersion to have `feature/*` branches both track `develop` **and** `release/*` branches simultaneously. At least not without a pull...

Please see the discussion in #3101.

What GitVersion did before #478 is impossible for me to answer. I have no idea. 🤷🏼 When it comes to the test you've written, I think `1.3.0-alpha.5` makes sense because...

What happens if you remove `next-version: 1.0.0`?