build number is lower than previous

[nulltoken]

[johnsimons]

Shouldn't the number be always higher?
Also, shouldn't that number be padded with 0s ?

[johnsimons]

I see the number is padded on the nuget package :)

[SimonCropp]

you can debug into this by modifying one of the integration tests here https://github.com/Particular/GitFlowVersion/blob/master/Tests/IntegrationTests.cs

[andreasohlund]

It seems to happen when we merged the hotfix into master generating the merge commit Particular/NServiceBus@fcf57f3

I think the bug here is that we stop calculating as soon as we find a commit thats both on develop and master which will happen when we do a hotfix?

cc @nulltoken @SimonCropp

[nulltoken]

I'll take a look at this tomorrow

[nulltoken]

I've started to analyze the issue. However, before diving into the code, I'd like to make sure that I correctly understand what the Unstable part should be.

Graph 1

master  -----B--
                \
develop --A------C----D

Graph 2

hotfix1           --E--
                 /      \
master  -----B-----------F
                \         \
develop --A------C----D----G--H

Graph 3

hotfix2                      --I--
                           /      \
hotfix1           --E--   /        \
                 /      \/          \
master  -----B-----------F-----------J
                \         \
develop --A------C----D----G--H----------K

• B is tagged 1.2.0
• F is tagged 1.2.1
• J is tagged 1.2.2

What should be unstable part of

• D in Graph 1
• H in Graph 2
• K in Graph 3

[nulltoken]

However, before diving into the code

Actually, I already dove into the code, but I'd like to get a higher level picture of "what should be expected" rather than "how we're doing it now".

[nulltoken]

The awesome @andreasohlund explained me (in a very gentle and polite way) that my graphs were nice... but somewhat irrelevant as they do not conform to GitFlow. #sadtrombone

So, I've made a new one (see below). And I hope it's better (@andreasohlund, @SimonCropp ?).

I've started to work on unit tests that would render the version for each commit as time goes by. A pull request in GFV should follow soon.

    hotfix-1.2.1       -----------C--      
                      /              \     
    master           A----------------F-----H-------N
                      \                    / \     /
    hotfix-1.3.1       \                  /   ----L
                        \                /         \
    release-1.3.0        \        -D----G---        \
                          \      /          \        \
    develop                -----B----E-------I-----M--O--P
                                      \           /
    feature                            -------J-K-

• A is tagged 1.2.0
• F is tagged 1.2.1
• H is tagged 1.3.0
• N is tagged 1.3.1

[nulltoken]

Here's the output of GitVersionFinder for the corresponding commits.

Commit B (develop) = 1.3.0-Unstable2
Commit C (hotfix-1.2.1) = 1.2.1-Beta0.1
Commit D (release-1.3.0) = 1.3.0-Beta0.1
Commit E (develop) = 1.3.0-Unstable3
Commit F (master) = 1.2.1
Commit G (release-1.3.0) = 1.3.0-Beta0.2
Commit H (master) = 1.3.0
Commit I (develop) = 1.4.0-Unstable1
Commit J (feature) = 1.4.0-Feature-feature-0491c5dac30d706f4e54c5cb26d082baad8228d1
Commit K (feature) = 1.4.0-Feature-feature-1b9cff4589e2f37bc624a18c349b7d95c360aaf7
Commit L (hotfix-1.3.1) = 1.3.1-Beta0.1
Commit M (develop) = 1.4.0-Unstable4
Commit N (master) = 1.3.1
Commit O (develop) = 1.4.0-Unstable7
Commit P (develop) = 1.4.0-Unstable8

Thoughts?

[nulltoken]

Below my own view. Beware, there are huge chances I'm completely off 😬.

• B looks bogus. Should be 1.3.0-Unstable1
• Similarly E should be 1.3.0-Unstable2
• I should be 1.4.0-Unstable2 (ie. E hasn't been merged in master)
• M should be 1.4.0-Unstable5
• O should be 1.4.0-Unstable6
• P should be 1.4.0-Unstable7

[nulltoken]

Ok. I've got a patched version of DevelopVersionFinder that produces the following output. This seems legit to me. However, there are a ton of tests that now fail. Before diving in and fixing them, I'd prefer to get some feedback.

@andreasohlund @SimonCropp Would this versioning scheme fit you?

Commit B (develop) = 1.3.0-Unstable1
Commit C (hotfix-1.2.1) = 1.2.1-Beta0.1
Commit D (release-1.3.0) = 1.3.0-Beta0.1
Commit E (develop) = 1.3.0-Unstable2
Commit F (master) = 1.2.1
Commit G (release-1.3.0) = 1.3.0-Beta0.2
Commit H (master) = 1.3.0
Commit I (develop) = 1.4.0-Unstable2
Commit J (feature) = 1.4.0-Feature-feature-0491c5dac30d706f4e54c5cb26d082baad8228d1
Commit K (feature) = 1.4.0-Feature-feature-1b9cff4589e2f37bc624a18c349b7d95c360aaf7
Commit L (hotfix-1.3.1) = 1.3.1-Beta0.1
Commit M (develop) = 1.4.0-Unstable5
Commit N (master) = 1.3.1
Commit O (develop) = 1.4.0-Unstable6
Commit P (develop) = 1.4.0-Unstable7

[nulltoken]

@andreasohlund As we agreed on the new commit counting scheme, I've transformed this issue into a pull request with a first version.

Next step is to fix all the failing tests... Less fun 😉

[andreasohlund]

Nice!

Ot: How did you transform? (did you use the issue2pr site?)

[nulltoken]

Ot: How did you transform? (did you use the issue2pr site?)

I did :)

Using the following:

• Issue url = https://github.com/Particular/GitVersion/issues/79
• HEAD = Particular:ntk/counting
• Base = master

[andreasohlund]

@nulltoken this needs a rebase because of #135

[JakeGinnivan]

@andreasohlund @nulltoken I stole the core fix from this PR already in #135

Would be good to bring the tests across. @nulltoken have a look at the acceptance test project, see if you like the format of the test.

I also started deleting tests which I felt were not giving us much and we could cover with high level integration tests

[andreasohlund]

@nulltoken what is the status on this one? (close or rebase?)

[andreasohlund]

Ping @nulltoken

[nulltoken]

@andreasohlund Done. The fix has already been added by @JakeGinnivan. I rebased the tests.