Add demo test screnario

[bitbonk]

This PR is only here to demonstrate my problem described in the discussion #3177

[asbjornu]

Thanks for providing a test! It is, however, a bit long and hard to follow. Could you please reduce it to a minimum and explain with comments which assertions in it fail and why you expect the version to be something else that what GitVersion produces?

[asbjornu]

To start with a 1.0.0 version, you just need to add a git tag. You can do that in a test with fixture.Repository.MakeATaggedCommit("1.0.0").

[bitbonk]

Making a tagged commit is a bit weird. When looking at the commit log, it looks like as if that commit was the 1.0.0 release.
That's what a version tag usually denotes (I would think)..
Also I was told, that using NextVersion in the config is a good approach here: #3123

[bitbonk]

The goal of this test was to describe the git workflow that I thought would be ideal and "suggested" as the default GitVersion flow.

The test does exactly what I described in #3177. It's the same thing but written as a test.

In this test only the last assertion fails. I think it is weird that the version on develop decrements.

I will try to create another, more reduced test.

[asbjornu]

I understand. Thank you for taking the time to write up such a thorough test. However, unless I've done something very strange, the test succeeds if you add the fixture.Repository.MakeATaggedCommit("1.0.0"); at the very beginning, as I suggested.

[bitbonk]

@asbjornu

I understand. Thank you for taking the time to write up such a thorough test. However, unless I've done something very strange, the test succeeds if you add the fixture.Repository.MakeATaggedCommit("1.0.0"); at the very beginning, as I suggested.

That's because the old test only verifies that the semantic version increments. Try it in the new test, it won't work there.
Also, see my comment above.

Making a tagged commit is a bit weird. When looking at the commit log, it looks like as if that commit was the 1.0.0 release.
That's what a version tag usually denotes (I would think).
Also I was told, that using NextVersion in the config is a good approach here: #3123

[bitbonk]

@asbjornu I have created a reduced, simplified test in ReducedGitFlowWithMerge.
All red emojis mark some sort of problem. 😉

[bitbonk]

@asbjornu OK I think this whole thing drills down to:
How can make develop start with 1.0.0-alpha.X in a brand new repo and at the same time have only X incremented on develop until the final release of 1.0.0 has actually happened (is merged into main)?

[asbjornu]

It is absolutely the case that next-version should give you the behavior you expect. Unfortunately, there is something in the handling of next-version that makes it not work like a git tag, which is unfortunate. For some use cases next-version works just fine, but for others, it does not. I consider that a bug and would like to see this fixed by having next-version: 1.0.0 work exactly like git tag 1.0.0. However, until that bug is fixed, I think you will have to use git tag to achieve the behavior you want.

[bitbonk]

I think you will have to use git tag to achieve the behavior you want.

Unfortunately tagging develop with 1.0.0 does not give me behavior I want. This will cause versions on develop have a 1.0.0 version (without the -alpha). The initial (complicated) test was just asserting that the semantic version increments that why it accidentally passed, my test was not exact enough.

[bitbonk]

I would suggest do continue discussion on #3177 instead of in this PR, if necessary.

[asbjornu]

Unfortunately tagging develop with 1.0.0 does not give me behavior I want. This will cause versions on develop have a 1.0.0 version (without the -alpha).

That only happens if you tag on the develop branch, no? Stable tags should preferably go on the main branch. At least, that's what GitVersion expects.

The initial (complicated) test was just asserting that the semantic version increments that why it accidentally passed, my test was not exact enough.

I see.

[asbjornu]

Did #3190 resolve this?

[bitbonk]

I will only be able to test this next week - but I will.

[bitbonk]

Did #3190 resolve this?

@asbjornu I was just trying to build the main branch locally (using Rider), and I am getting the following two errors:

GitVersion.Core: Invalid option '11' for /langversion. Use '/langversion:?' to list supported values.
GitTools.Testing: Invalid option '11' for /langversion. Use '/langversion:?' to list supported values.

What are the prerequisites to get the main branch built?

[arturcic]

@bitbonk we recently merged the .net 7 support so you should install the rc2 for now, and in couple of weeks the final release of .net 7.0

[bitbonk]

OK, running the test with the new changes yield some slightly changed behavior on how the versions (major, minor, patch and -alpha.commits) are incremented which is probably OK (as far as I can tell) but my main problem that there were scenarios where the semver on the develop could actually decrement does not exist anymore.

Good job 👍🏻and thank you! Following along as the PRs progressed, it sure looked like a lot of hard work.

What release will include these changes?

[arturcic]

@bitbonk the new major version - v6, but we don't have an exact time we release it, but most probably soon we'll start publishing first alphas or betas of v6 to get first feedback