GitVersion icon indicating copy to clipboard operation
GitVersion copied to clipboard

Add demo test screnario

Open bitbonk opened this issue 3 years ago β€’ 9 comments

This PR is only here to demonstrate my problem described in the discussion https://github.com/GitTools/GitVersion/discussions/3177

bitbonk avatar Sep 09 '22 16:09 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.

bitbonk avatar Sep 10 '22 10:09 bitbonk

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.

asbjornu avatar Sep 10 '22 10:09 asbjornu

@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: https://github.com/GitTools/GitVersion/discussions/3123

bitbonk avatar Sep 10 '22 12:09 bitbonk

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

bitbonk avatar Sep 10 '22 12:09 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)?

bitbonk avatar Sep 10 '22 13:09 bitbonk

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.

asbjornu avatar Sep 10 '22 22:09 asbjornu

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 avatar Sep 11 '22 15:09 bitbonk

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

bitbonk avatar Sep 11 '22 15:09 bitbonk

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 avatar Sep 11 '22 20:09 asbjornu

Did #3190 resolve this?

asbjornu avatar Oct 25 '22 09:10 asbjornu

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

bitbonk avatar Oct 25 '22 18:10 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?

bitbonk avatar Oct 27 '22 13:10 bitbonk

@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

arturcic avatar Oct 27 '22 13:10 arturcic

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?

bitbonk avatar Oct 27 '22 14:10 bitbonk

@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

arturcic avatar Oct 27 '22 14:10 arturcic