Classic version and MajorMinorPatchMetadata

[GeertvanHorrik]

VariableProvider resets the CommitsSinceTag:

                // For continuous deployment the commits since tag gets promoted to the pre-release number
                semanticVersion.PreReleaseTag.Number = semanticVersion.BuildMetaData.CommitsSinceTag;
                semanticVersion.BuildMetaData.CommitsSinceTag = null;

So the AssemblySemVer will never have the right last number?

1. Why is it reset to null? Am I not understand the VersioningMode correctly?
2. A possible fix would be this change in AssemblyVersionsGenerator:

return string.Format("{0}.{1}.{2}.{3}", sv.Major, sv.Minor, sv.Patch, sv.BuildMetaData.CommitsSinceTag ?? sv.PreReleaseTag.Number ?? 0);

[JakeGinnivan]

This is only in continuous delivery mode which overwrites patch with number commits, doesn't make sense to change 1.2.3-beta.4 to 1.2.4-beta.4, just make it 1.2.4-beta.

Sent from my Windows Phone

---

From: Geert van Horrikmailto:notifications@github.com
Sent: ý14/ý03/ý2015 15:33
To: ParticularLabs/GitVersionmailto:GitVersion@noreply.github.com
Subject: [GitVersion] Classic version and MajorMinorPatchMetadata (#391)

VariableProvider resets the CommitsSinceTag:

            // For continuous deployment the commits since tag gets promoted to the pre-release number
            semanticVersion.PreReleaseTag.Number = semanticVersion.BuildMetaData.CommitsSinceTag;
            semanticVersion.BuildMetaData.CommitsSinceTag = null;

So the AssemblySemVer will never have the right last number?

1. Why is it reset to null? Am I not understand the VersioningMode correctly?
2. A possible fix would be this change in AssemblyVersionsGenerator:

return string.Format("{0}.{1}.{2}.{3}", sv.Major, sv.Minor, sv.Patch, sv.PreReleaseTag.Number);

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/391.

[GeertvanHorrik]

But you set it to null for continuous deployment (so is this a bug?). I think there is a difference between 1.2.3-beta3 and 1.2.3-beta4.

[JakeGinnivan]

It is inside if (mode == VersioningMode.ContinuousDeployment && !currentCommitIsTagged)

I actually meant continuous deployment in my example above.

The logic and reasoning is explained in the readme at https://github.com/ParticularLabs/GitVersion#octopus-deployci-build-nuget-packages

[GeertvanHorrik]

Still not sure I understand, but let's close this issue.

[JakeGinnivan]

In short, there are two modes. Continuous delivery and continuous deployment.

Continuous delivery will bump the BuildMetaData.CommitsSinceTag each commit which doesn't change the SemVer.

Continuous deployment mode promotes the changing CommitsSinceTag to be the Pre-release number. And I didn't see any point having the same number duplicated as you get

1.2.3-beta.1+1
1.2.3-beta.2+2
etc

I just drop the +1 by nulling it out. Make sense?

[JakeGinnivan]

If I can improve the docs to explain better or something then I am interested in doing that, just not sure of the exact issue you are reporting so my answers might be missing

[GeertvanHorrik]

So you are saying, in Continuous deployment, I should be able to get 1.2.3.1 when I specific MajorMinorPatchMetadata?

[JakeGinnivan]

Hrrmm, ok I think the problem is the MajorMinorPatchMetadata itself.. we never take into account the build number.. So 1.2.3-beta.4+5 will either be 1.2.3.4 or 1.2.3.0, which is wrong as you say. I am following you now..

I think we should drop MajorMinorPatchMetadata, it doesn't make sense.. What do you think?

[JakeGinnivan]

I think falling back through different things is not great.

Out of interest what are you using it for?

[JakeGinnivan]

or we change it to be MajorMinorPatchTag so 1.2.3-beta.4+5 will be 1.2.3.4 or in continuous delivery mode it will be 1.2.3.5.

Then the issue is with stable, when it is stable we start bumping the patch on every commit meaning it will always be .0 at the end.

At any rate, I think this is a bad idea as we are trying to make a tool for SemVer?

[GeertvanHorrik]

What I did in the past was using ClassicVersion, but that is dropped now in v3. I was looking for the alternative, so found AssemblySemVer (or something like that). However, I found it strange that 2.1.0-unstable.13 wouldn't result in version 2.1.0.13.

Then I created this issue. Then I decided: hmmm, 2.1.0 isn't a bad idea. I will keep 2.1.0 as file version, but use the FullSemVer as InformationalVersion, so decided to put back MajorMinorPatch.

So that's a bit of history. However, I think if a user wants to stamp it as 2.1.0.13, it should be allowed using MajorMinorPatchMetadata. If the user wants 2.1.0.0, he/she should use MajorMinorPatch (which is the default).

[JakeGinnivan]

Makes sense. Sorry, missed the point of the original issue. Will have a think and add some tests around it to see what makes sense