next-version as base version?

[vernou]

In this documentation page "Version Incrementing":

The first is by setting the next-version property in the GitVersion.yml file. This property only serves as a base version,

But it his other page "Configuration":

Since version 5.5 GitVersion supports next-version with mode: Mainline and should not be treated as a "base version".

These indications are inconsistent. Can I use next-version as base version? Or not and why?

---

EDIT :

I don't understand the notion of base version from the doc, but I assume a base version is the startup version that serve to begin the count. With the base version 5.3.4, the result is 5.3.4 or more (following the regular rule). It's convenient to integrate GitVersion in existing project.

From my tests, it's the behavior of next-version I observe... But I am very confused by this sentence in the doc :

next-version ... should not be treated as a "base version".

Maybe I can just ignore this caution.

[HHobeck]

Hmm what is the definition of base version? next-version works not with mainline mode and should be only used in non-trunk based workflows. I think the documentation needs to be changed.

[vernou]

what is the definition of base version?

I updated my question to define base version.

next-version works not with mainline mode

From my tests, it's work fine... Why it don't work?

[HHobeck]

If you take this scenario you see a very strange behavior:

[Test]
public void _Just_A_Test__()
{
    var configuration = GitHubFlowConfigurationBuilder.New.WithNextVersion("1.1.0")
        .WithBranch("main", _ => _.WithVersioningMode(VersioningMode.Mainline))
        .WithBranch("feature", _ => _.WithVersioningMode(VersioningMode.Mainline).WithIncrement(IncrementStrategy.Major))
        .Build();
    using var fixture = new EmptyRepositoryFixture("main");

    fixture.MakeATaggedCommit("1.0.0");

    fixture.BranchTo("feature/foo");
    fixture.MakeACommit();
    fixture.MakeACommit();
    fixture.MakeACommit();

    // ❌ expected: 2.0.0-foo.3
    fixture.AssertFullSemver("1.0.0-foo.3", configuration);

    fixture.Checkout("main");
    fixture.MergeNoFF("feature/foo");

    // ❌ expected: 2.0.0
    fixture.AssertFullSemver("1.1.0", configuration);
}

I'm not the author of next-version. But you can think of using this to bump the version to a higher value for what ever reason. Please see the following user story #3177 (comment):

The point here is that you need to cancel the hole release and skip this number 1.0.0. You are deleting the release branch or even the develop branch and start again integrating the feature/A and feature/C into a new alpha version with the number 1.1.0 (or even 1.2.0 if the version 1.1.0 is burned too) and start the hole process from beginning. You could say but if I delete the release branch the next version will be just the 1.0.0 in the develop branch. Yes you are right but exactly for this use case the next version configuration or bump messages are good for in GitVersion.

Happy branching!

[goors]

It would be great if someone can explain this. Putting in next-version to some number like 6.0.0 or 6 for example will set semVersion to 6.0.0 and then you push again and you removed next-version, next version will be some 0.88.11 completely ignoring what you put in pervious time.....

[HHobeck]

I think deleting next-version before you have released your version to production on main is not a good idea. Normally you would specify next-version to bump your next-version to a higher version like in your example to 6.0.0. This version will be used until you release your software to production. After you have tagged your version on main you can remove it or keep it (it doesn't matter).

[goors]

Thank you. It is clear from your answer.